apps: stop planning an update on every deploy - #6328
Merged
Conversation
The backend enables user access token forwarding and reports forward_user_access_token as true even when the bundle omits it. The field became part of apps.App in databricks-sdk-go v0.171.0 and was added to the app update mask, but nothing classified it, so the direct engine read the remote true as drift: every plan reported "action": "update" with a remote value and no local one, and every deploy issued a no-op Apps update call. Declare it under backend_defaults, matching compute_size: the remote value is skipped when the config omits the field, while an explicit value in the config still diffs normally. The fake workspace did not model this default, which is why the regression reached the nightly integration tests instead of failing here. It now reports the field the way the platform does, which reproduces the spurious update without the fix. Co-authored-by: Isaac
Co-authored-by: Isaac
Contributor
|
This should have been caught by no_drift test on cloud. If it did not, could you take a look why not? |
shreyas-goenka
marked this pull request as ready for review
August 20, 2026 08:14
The fake workspace now reports the field, so the two goldens that dump raw app state (bundle generate and the apps command output) include it. Co-authored-by: Isaac
| @@ -0,0 +1 @@ | |||
| Fixed apps planning an update on every deploy. The backend enables `forward_user_access_token` and reports it as `true` even when the bundle omits it, which the direct engine read as drift and turned into a no-op update call on each deploy ([#6328](https://github.com/databricks/cli/pull/6328)). | |||
Contributor
There was a problem hiding this comment.
we don't need this changelog entry since the previous release wasn't affected (didn't have this SDK field)
The regression it described has not shipped in a release, so there is nothing user-visible to announce. Co-authored-by: Isaac
janniklasrose
approved these changes
Aug 20, 2026
Collaborator
Integration test reportCommit: 5e44f76
Top 6 slowest tests (at least 2 minutes):
|
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 free
to 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
The direct engine planned an Apps update on every deploy, so each
bundle deployissued a no-opApps.CreateUpdatecall. Every plan looked like this, with a remote value and no local one:forward_user_access_tokenbecame part ofapps.Appin databricks-sdk-go v0.171.0 (#6320) and was added to the app update mask, but nothing classified it. The backend enables token forwarding and reports it astrueeven when the bundle omits the field, so the remotetrueread as drift,hasAppChangesreturned true, and the update fired.Declared under
backend_defaults, exactly likecompute_size: the remote value is skipped when the config omits the field, while an explicit value in the config still diffs normally (so real drift is still caught).