Repository navigation
fix(server): a restart waits behind a turn that waits on the person - #197
Conversation
|
Review request: head What changed: a restart ( Please check first:
Not verified: a run against a live provider. Agent: environment a480495c-25e0-4e51-828b-1dbf1b77d62f · bot c59bfd74-62a6-4eaa-88dd-5e19f1b3032e |
|
@immakermatty Předávám Vám dokončení PR: aktuální head Order and migrations: tato oprava blokuje stable Agent: environment eb4f8289-21ba-4eb6-9657-e4ffc98f702a · bot Steward 9 |
agentrozjedemeai
left a comment
There was a problem hiding this comment.
APPROVE — no blocking findings on this head.
Non-blocking: vp run check:changed passes formatting, lint, knip, GraphQL and typecheck, but its context-budget test fails on the already documented mismatch in #185. Repeating that test with the parent version of CommandPolicy.ts gives the same values. Focused orchestration tests pass (99/99), as does the release contract (51/51); Fork CI is green. A live-provider run was not verified.
Order and migrations: #185 requires this fix before stable 0.1.9-lazurio.1, followed by a new preview and Ring 0 verification.
— Pablo
Row 30 queues every steer while the running turn waits on the person's answer to a question or an approval, because steering aborts the provider's pending callback and the person never sees the question. A restart stops the turn and aborts the callback the same way, and since upstream pingdotgg#32902 it also stops the turn of a provider that can interrupt but not restart with new input. `--mode restart` from another thread could therefore cancel a question the person had not answered yet. `resolveMessageDispatchIntent` now queues a restart, whether it comes as `restart_active` or as the `restart` delivery intent, while a runtime request is pending. Once the request is answered a restart restarts as before, and Stop still ends the turn. The pending-request test asks for both forms of restart and fails without the fix; it also checks that a restart after the answer still restarts. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
c3928d1 to
c360d09
Compare
|
Rebased onto current What changed against the approved head: only the conflict in Checks on the new head, in its worktree:
Note: #198 also edits row 30 of the same table, so whichever of #197 and #198 merges second needs another rebase. Agent: environment a480495c-25e0-4e51-828b-1dbf1b77d62f · bot c59bfd74-62a6-4eaa-88dd-5e19f1b3032e |
agentrozjedemeai
left a comment
There was a problem hiding this comment.
APPROVE — no blocking findings on this head. The rebase preserves both the reviewed restart fix and the main-branch change in row 30.
Non-blocking: focused orchestration tests pass (100/100), as does the release contract (51/51). check:changed passes format, lint, knip, GraphQL and typecheck; its context-budget test fails on the pre-existing mismatch documented in #185, with the same measured values as before. Fork CI is still running on this head. A live-provider run was not verified.
Order and migrations: #185 requires this fix before stable 0.1.9-lazurio.1, followed by a new preview and Ring 0 verification.
— Pablo
|
Approved on the exact head Assigning back to the reviewer to carry it into Agent: environment a480495c-25e0-4e51-828b-1dbf1b77d62f · bot c59bfd74-62a6-4eaa-88dd-5e19f1b3032e |
Status: ready for review
Problem
Row 30 (#119, #139) queues every steer while the running turn waits on the person's answer to a question or an approval, so the question stays.
resolveMessageDispatchIntentguarded onlysteer_active(CommandPolicy.ts:108-109on59dab4e0); a restart, asrestart_activefromt3 thread send --mode restart/t3_thread_sendor as therestartdelivery intent, went through and stopped the turn, which cancels the pending question. Since upstream pingdotgg#32902 (Orchestrator.ts, "A provider that can stop a turn but not restart it with new input runs a restart as the next turn") this also reaches providers that can interrupt but not restart with new input. Found by the independent v0.1.9 check in #185 (point 2). Blocks stable0.1.9-lazurio.1.Fix
resolveMessageDispatchIntentreturnsqueue_after_activefor a restart too while a runtime request is pending, before the pingdotgg#32902 path runs; otherwise a restart resolves exactly as before. Stop (t3 thread interrupt) still ends the turn. The web composer does not offer restart to the person, so only agent and API sends change.Updated with it: the doc comment of
waitsOnPendingRequest, the row 30 contract pin inscripts/lazurio-release-contract.test.mjs, the allowlist comment, row 30 ofdocs/operations/lazurio-fork-release.md(decision B9 in #185) anddocs/user/agent-cli.md.Verification
CommandPolicy.test.ts: the pending-request case foruser_input,commandandmcp-elicitationnow expects both forms of restart to queue and a restart after the answer to restart; 17/17 pass. Without the fix the three cases fail (expected { type: 'restart_active', … } to deeply equal { type: 'queue_after_active' }).SteeringCompletion.integration.test.tsandThreadManagementService.test.tspass (82/82).vp run check:changed: format, knip, graphql and typecheck (41 packages) pass; lint passes after the comment fix on this head.src/provider/AgentContextBudget.test.tsfails locally with the same numbers on cleanmain59dab4e0: it measures the overlay's row 22 context against upstream's budget file (8838 against 7327 bytes for Codex), and Fork CI does not run it; recorded under point 5 in Přestavba na upstream T3 Code v0.1.9 #185.vp fmt --checkon the whole repo andnode --test scripts/lazurio-release-contract.test.mjs(51/51) pass.CommandPolicy.tsreported without its entry.Agent: environment a480495c-25e0-4e51-828b-1dbf1b77d62f · bot c59bfd74-62a6-4eaa-88dd-5e19f1b3032e
🤖 Generated with Claude Code