fix(orchestrate): re-apply the component state leaf on a rejected finalize push - #537
Merged
Merged
Conversation
…alize push The Go orchestrate finalize path committed the state leaf once and then relied on a textual git pull --rebase to land it, so two component finalizes appending adjacent leaves under state.components conflicted on the rebase and hard-failed, despite a doc-comment claiming the loop re-runs the write. The promote, hotfix, and rollback finalizers already re-derive and re-apply their owned leaf per attempt. Add a WithReapply option to the shared push-retry: on a rejected push it re-fetches trunk, resets away the stale local commit, and re-derives the owned leaf onto the fresh bytes before retrying, so a concurrent sibling's leaf survives. Wire it for component-scoped orchestrate runs only, leaving single-component finalize on the textual path byte-identical. Raise the retry count to ten with exponential jittered backoff and emit a per-attempt log line. Correct the false doc-comment. Signed-off-by: Joshua Temple <joshua.temple@stablekernel.com>
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.
Problem
The Go
orchestrate finalizepath committed the state leaf once, then relied on a textualgit pull --rebaseto land it. Two component finalizes appending adjacent leaves understate.componentsconflict on that rebase and hard-fail, despite a doc-comment claiming the retry loop re-runs the write. The promote, hotfix, and rollback finalizers already re-derive and re-apply their owned leaf per attempt; orchestrate was the outlier.Fix
Add a
WithReapply(func() error)option to the shared push-retry. On a rejected (non-fast-forward) push it re-fetches trunk, resets away the stale local commit, and invokes the closure to re-derive the owned leaf onto the fresh trunk bytes before retrying, so a concurrent sibling's leaf survives. Wired for component-scoped orchestrate runs only; single-component finalize stays on the textual path, byte- and behavior-identical. Retry count raised 3 to 10 with exponential jittered backoff, and a greppable per-attempt log line is emitted (live-proof instrumentation for a later stage). The false doc-comment is corrected.Scope / safety
PushWithRebaseRetryis orchestrator-only; promote uses a separateCommitAndPushWithRetry; neither promote/hotfix/rollback passesWithReapply, so there is no double-apply.component != "").Verification
New tests: two component lanes append adjacent leaves and B lands first, so A must re-apply; asserts all leaves survive (red-before proven by disabling the wiring, green-after); a regression guard that the old textual path conflicts.
go build,go test ./... -race(2667 pass),golangci-lintall clean.