fix(sequencer): gate standalone fallback prune on build-start deadline#24488
Closed
spalladino wants to merge 1 commit into
Closed
Conversation
The proposer fallback `tryVoteAndPruneWhenCannotBuild` enqueued a standalone `prune` whenever it could propose, without checking the build-start deadline. On a transient pre-deadline sync miss (`checkSync` momentarily failing while the archiver caught up) the fallback fired a standalone prune that raced the imminent build — which bundles the prune inside `propose` on the happy path — and landed alone on L1, resetting the rollup checkpoint. Gate the standalone prune on `now > getBuildStartDeadline(targetSlot)` so it only fires once building the target-slot checkpoint is genuinely no longer possible. Votes still fire regardless of the deadline (kept from before, since under pipelining the target advances with the clock and gating votes on the deadline can miss the fallback window). Track votes and prune with separate per-slot guards (`lastSlotForFallbackVote` and `lastSlotForFallbackPrune`) so a pre-deadline vote pass no longer consumes the slot's later prune opportunity — otherwise a persistently-stuck proposer, which ticks pre-deadline first every slot, would be starved of the standalone prune that recovers a wedged pending chain. The prune block re-reads the clock so a deadline crossed during the vote/publisher awaits still prunes in the same work-loop iteration.
Contributor
Author
|
Closing in favor of #24504 |
PhilWindle
pushed a commit
that referenced
this pull request
Jul 5, 2026
Sequencer defines a set of fallback actions (voting and pruning) which are meant to be executed if it fails to propose a checkpoint, due to sync errors. However, those actions were being triggered as soon as the sequencer sync check failed, even if in the next sequencer iteration the check succeeded and the sequencer managed to produce a block. Now, the sequencer waits until it's past its build deadline (too late within the build slot to actually build anything), and only then triggers the fallback actions. Fixes A-1362 Supersedes #24488
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.
Context
The proposer fallback
tryVoteAndPruneWhenCannotBuildenqueued a standaloneprunewhenever it could propose, without checking the build-start deadline. On a transient pre-deadline sync miss (checkSyncmomentarily failing while the archiver caught up), the fallback fired a standalone prune that raced the imminent build — which bundles the prune insideproposeon the happy path — and landed alone on L1, resetting the rollup checkpoint. This surfaced as a flake inproof_fails.parallel.test.ts(the test read checkpoint 0 after the standalone prune landed).Approach
now > getBuildStartDeadline(targetSlot), so it only fires once building the target-slot checkpoint is genuinely no longer possible. A pre-deadline sync miss is treated as transient: retry and, if sync recovers, build normally (bundling any prune intopropose).lastSlotForFallbackVoteandlastSlotForFallbackPruneguards. Without this, a persistently-stuck proposer — which ticks pre-deadline first every slot — would vote-only, set the shared guard, and be starved of the standalone prune that recovers a wedged pending chain. The prune block also re-reads the clock so a deadline crossed during the vote/publisher awaits still prunes in the same work-loop iteration.enqueuePruneIfPrunable; and a pre-deadline vote pass followed by crossing the deadline in the same slot still enqueues the prune.Fixes A-1362