Uh oh!
There was an error while loading. Please reload this page.
Add error for when an etag is specified in dashboard configuration - #3723
Merged
Conversation
shreyas-goenkatemporarily deployed
to
test-trigger-is
October 6, 2025 09:18 — with 
GitHub Actions
Inactive
shreyas-goenkatemporarily deployed
to
test-trigger-is
October 6, 2025 09:21 — with GitHub Actions
Inactive
shreyas-goenka
marked this pull request as ready for review
October 6, 2025 09:21
shreyas-goenka
requested review from
andrewnester, anton-107, denik and pietern
as code ownersOctober 6, 2025 09:21
shreyas-goenkatemporarily deployed
to
test-trigger-is
October 6, 2025 09:24 — with GitHub Actions
Inactive
pietern
reviewed
Oct 6, 2025
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
shreyas-goenkatemporarily deployed
to
test-trigger-is
October 6, 2025 12:34 — with GitHub Actions
Inactive
shreyas-goenkatemporarily deployed
to
test-trigger-is
October 6, 2025 12:34 — with GitHub Actions
Inactive
pietern
approved these changes
Oct 6, 2025
shreyas-goenkatemporarily deployed
to
test-trigger-is
October 6, 2025 12:39 — with GitHub Actions
Inactive
shreyas-goenka
enabled auto-merge
October 6, 2025 12:40
denik
reviewed
Oct 6, 2025
| validate.Enum(), | ||
| // Validate that no dashboard etags are set. They are purely internal state and should not be set by the user. | ||
| validate.ValidateDashboardEtags(), |
Contributor
There was a problem hiding this comment.
Would not resourcemutator be a better place for this? Currently this misses resources set by PyDABs.
Related, can we have an abstraction similar to SetDefault() that allows us easily adding output-only fields?
MustNotBeSet("resources.dashboards.*.etag"),
ContributorAuthor
There was a problem hiding this comment.
This validation happens after PyDABs resources are loaded.
can we have an abstraction similar to SetDefault() that allows us easily adding output-only fields?
Longer term, perhaps. We can autogenerate those based on OUTPUT only or other annotations. For now we don't need to generalize.
ContributorAuthor
There was a problem hiding this comment.
MustNotBeSet("resources.dashboards.*.etag")
In this case I opted for the static types because those are easier to discover / navigate. Eventually we can use the dynamic paths but I don't want to do that prematurely here.
Contributor
There was a problem hiding this comment.
This validation happens after PyDABs resources are loaded.
Right, I did not notice.
denik
approved these changes
Oct 6, 2025
shreyas-goenkatemporarily deployed
to
test-trigger-is
October 6, 2025 13:33 — with GitHub Actions
Inactive
andrewnester
approved these changes
Oct 7, 2025
shreyas-goenka
disabled auto-merge
October 7, 2025 13:42
shreyas-goenkatemporarily deployed
to
test-trigger-is
October 7, 2025 13:43 — with GitHub Actions
Inactive
shreyas-goenkatemporarily deployed
to
test-trigger-is
October 8, 2025 09:36 — with GitHub Actions
Inactive
Collaborator
11 failing tests:
|
Uh oh!
There was an error while loading. Please reload this page.
deco-sdk-taggingBot
added a commit
that referenced
this pull request
Oct 8, 2025
## Release v0.272.0 ### Bundles * Fix processing short pip flags in environment dependencies ([#3708](#3708)) * Add support for referencing local files in -e pip flag for environment dependencies ([#3708](#3708)) * Add error for when an etag is specified in dashboard configuration. Setting etags was never supported / valid in bundles but now users will see this error during validation rather than deployment. ([#3723](#3723)) * Fix PIP flag processing in pipeline environment dependencies ([#3734](#3734))
denik pushed a commit
that referenced
this pull request
May 20, 2026
…3723) ## Changes Users should never set etags in their configuration. It's meant to be a pure internal state. ## Why This validation can potentially help simplify downstream code since we can read etags directly from a merged view of (config + state) and be confident that the etag values come from state. Note: This is not a breaking change since existing users would see errors when they try to update their dashboard if they specified etags in their configuration today: ``` databricks_dashboard.dashboard: Modifying... [id=01f0a29746cd1d1991ae7cc9e6331576] ╷ │ Error: cannot update dashboard: Entity etag provided does not match currently stored etag. Please reload the entity and try the action again. │ │ with databricks_dashboard.dashboard, │ on main.tf line 13, in resource "databricks_dashboard" "dashboard": │ 13: resource "databricks_dashboard" "dashboard" { │ ╵ ``` ## Tests New acceptance test.
denik pushed a commit
that referenced
this pull request
May 20, 2026
## Release v0.272.0 ### Bundles * Fix processing short pip flags in environment dependencies ([#3708](#3708)) * Add support for referencing local files in -e pip flag for environment dependencies ([#3708](#3708)) * Add error for when an etag is specified in dashboard configuration. Setting etags was never supported / valid in bundles but now users will see this error during validation rather than deployment. ([#3723](#3723)) * Fix PIP flag processing in pipeline environment dependencies ([#3734](#3734))
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
Users should never set etags in their configuration. It's meant to be a pure internal state.
Why
This validation can potentially help simplify downstream code since we can read etags directly from a merged view of (config + state) and be confident that the etag values come from state.
Note: This is not a breaking change since existing users would see errors when they try to update their dashboard if they specified etags in their configuration today:
Tests
New acceptance test.