Fix config-remote-sync error when a remote rename is reverted before redeploy#5251
Open
ilyakuz-db wants to merge 1 commit into
Open
Fix config-remote-sync error when a remote rename is reverted before redeploy#5251ilyakuz-db wants to merge 1 commit into
ilyakuz-db wants to merge 1 commit into
Conversation
…redeploy When a keyed element (e.g. a job task) is renamed in the workspace, synced into local config via `config-remote-sync --save` without an intervening redeploy, and then renamed back to the original key, the next sync errored with: failed to resolve selectors in path resources.jobs.X.tasks[task_key=Y]: no array element found with task_key=Y In that state the saved state still holds the original key, the local config holds the intermediate key from the first sync, and the remote holds the original key again. `convertChangeDesc` was using `hasConfigValue := cd.Old != nil || cd.New != nil`, so the change on the original-key path was classified as `Replace` even though the YAML no longer contains that key — `resolveSelectors` then failed. Only the current config (`cd.New`) should decide whether a path exists on "the config side". With this change the operation becomes `Add` and the existing `indicesToReplaceMap` logic in `ResolveChanges` pairs it with the matching `Remove` to produce a clean rename in the YAML. Adds a table-driven unit test for `convertChangeDesc` and an acceptance test (`acceptance/bundle/config-remote-sync/task_rename_revert`) that reproduces the full rename-and-revert flow.
ilyakuz-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
ilyakuz-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Contributor
Approval status: pending
|
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
1 participant
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
In
convertChangeDesc, use only the current local config (cd.New) to decide whether a path exists "on the config side"; do not include the saved state (cd.Old).Why
When a keyed element (such as a job task) is renamed on the remote workspace, synced into local config via
databricks bundle config-remote-sync --savewithout an intervening redeploy, and then renamed back to the original key, the next sync would fail with:In that state the saved state still held the original key
Y, the local config held the intermediate key from the first sync, and the remote heldYagain. The oldhasConfigValue := cd.Old != nil || cd.New != nilclassified the change on theYpath asReplace, but the YAML no longer containedY, soresolveSelectorserrored out.With the change, the operation is correctly classified as
Add, and the existingindicesToReplaceMaplogic inResolveChangespairs it with the matchingRemoveto produce a clean rename in the YAML.Tests
convertChangeDesccovering Add / Remove / Replace / Skip and the regression case.acceptance/bundle/config-remote-sync/task_rename_revertwhich walks through the full rename-and-revert flow end-to-end.