Hold the base workflow lock while forking reset history - #12008
Draft
taylan-oai wants to merge 1 commit into
Draft
taylan-oai wants to merge 1 commit into
taylan-oai wants to merge 1 commit into
Conversation
|
|
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
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.
Summary
Hold the base workflow lock until a replicated reset publishes its history branch, closing the gap where retention cleanup can run between lookup and fork.
Problem
The replicated-reset path loads the base workflow to select a history branch, then releases its workflow-cache lock before calling
ForkHistoryBranch. Retention cleanup acquires that same lock and can delete the base history during the gap, before the reset branch exists as a reference.Approach
Select and fork the branch within the existing base-workflow lease. Release the lease after the fork succeeds or fails, before rebuilding the reset workflow. Preserve the existing retry response for missing history and the storage layer's rewritten branch tokens.
Validation
Risks, rollout, and scope
The base workflow lock is held across one additional persistence call. Fork errors now reach the lease release function, which follows the existing cache error handling.
This closes the same-owner retention-cleanup gap in replicated resets. It does not add storage-level fencing across shard ownership changes or administrative force deletion. The regression establishes lock ordering; it does not reproduce a complete workflow with missing history or establish production frequency. No schema or API migration is required.