Repository navigation
fix(vendor): open a message run when parked work resumes with none open - #139
Merged
TheGreatAxios merged 3 commits intoNov 4, 2026
Conversation
Parked work resumed while no message run is open (after a restart, or after the run that parked it closed) never opened a run, so it reported no start and no end and consumers saw the agent as working forever. The resumed work opens a run when none is open, named for the message that resumed it when there is one; a resume that arrives while a run is open stays in that run. This covers decided and timed-out approvals and answered async correlations.
brianjfox
marked this pull request as ready for review
November 4, 2026 09:53
…in-vendored-interchange
|
Triage: In progress Triage is waiting for code review before it decides. This comment shows the verdict once it has. |
TheGreatAxios
enabled auto-merge
November 4, 2026 16:36
A gate clear that lands while its suspend is still committing is replayed after reactor.gate.blocked. The replay dropped the correlated message, so a run opened for that resume would carry no message id or inference options. Today the suspending run is always still open when the replay lands, so this only keeps the vendored patch consistent.
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.
Problem
When the coordinator asks for approval, it parks and waits. If the approval is decided after the hub restarts, or after the turn that asked has already closed, the coordinator picks the work back up but never reports that a turn started or ended. The project page and the hub's activity read then show the coordinator as "working" until the next message arrives, even though it already finished.
The same thing happens when an approval times out, or when a reply to an async tool call arrives late.
Fix
In vendored Interchange's reactor, resumed work now opens its own turn (
message.run.started/message.run.ended) whenever no turn is open. The turn is named after the message that resumed it, if there is one. If a turn is already open when the work resumes, the work joins it as it did before.A follow-up commit makes sure the resuming message also survives a rare timing case: the gate clears while the reactor is still saving the park.
Nothing in Builder reads which message a turn belongs to. The web app and the hub only use the start and end to decide whether the coordinator is working, so a turn with no message name (from a timeout) changes nothing for them.
Vendoring
This changes
vendor/interchange(the reactor, plus comments ingates.tsandinference-events.ts), andvendor/interchange.manifest.jsonrecords the new files. Upstream Interchange is not changed yet. That's tracked in INTR-721, and once it lands upstream this patch can be dropped.Verification
bun run lint,format:check,typecheck,test,pins:verifyandvendor:verifypass.main; the still-open control passes on both.Closes CL-12080