refactor(core): advance sessions before running steps - #45358
Merged
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.
Why
The Session runner distributes inbox scheduling across its drain loop, nested Step loop, and separate compaction/move probes. Its retry loop also carries input-promotion state even though promotion only happens before the first attempt.
What Changes
The drain now alternates between advancing the Session and executing a logical Step:
advanceToStepowns eligible control dispatch, instruction preparation, input promotion, and the first loaded context.runStepreceives that context and a fixed logical step number; later attempts refresh context without delivering more input.runSteps,eligible, the separate pending-compaction/move helpers, and the one-use Session lookup helper.Scheduling Contract
advanceToStepexactly onceManual compaction delivery and start remain atomic. Its summary work remains interruptible and failure settlement stays protected. Movement returns to process-global execution to acquire the destination Location.
Scope
Core runner sequencing only. No queue/steer policy, public protocol, durable event, retry-budget, or manual-compaction interface change. Preserves the upstream background-recovery changes.
This is an alternative to #45335, not a stacked follow-up; the two approaches should not be combined. The independent interrupt/wait PR #45337 is unaffected.
Verification