Repository navigation
Cancel misses a batch mid-promotion, letting a cancelled request reach speculation #825
Description
Problem
A request cancelled in the window between dependency analysis claiming it (validated → batched) and promoting its batch out of creating reaches speculation anyway. The result is a live batch carrying a request the user cancelled; it will build, and it can merge.
Interleaving
dependency analysis: request validated → batched (claimRequestsForBatch)
cancel: request batched → cancelling (markCancelling)
cancel: findBatches sees only a creating batch — not cancellable
cancel: request cancelling → cancelled (no applicable batch → cancelRequest)
dependency analysis: batch creating → created (batch-only compare-and-swap)
dependency analysis: publish to speculate
Why the existing guards miss it
- The halted-request check in dependency analysis runs before the claim.
- The claim's re-read and version check reject a cancel that lands before or during the claim, but this window opens after the claim succeeds.
creatingis not cancellable, so cancel's batch loop matches nothing and falls through tocancelRequest.- Neither speculate's admission of
createdbatches nor conclude checks for halted requests.
Found in review of #590. As of 6c050082 the code paths above are unchanged.
Constraint
From #817: a batch abandoned in creating must stay unreachable, and created must remain dependency-eligible.
Activity
burgulvedant commentedon Oct 31, 2026
@behinddwalls I would like to work on this. Before I write code, which direction do you prefer?
I lean towards option 2. It closes the gap where the batch is used and leaves the creating and created rules from #817 untouched. Happy to follow whichever you pick.