Skip to content

fix(verify-mcode): read live turn events from agent.canonical - #1805

Merged
chuks-qua merged 2 commits into
mainfrom
fix/verify-mcode-canonical-live-events
Oct 6, 2026
Merged

chuks-qua merged 2 commits into
mainfrom
fix/verify-mcode-canonical-live-events

Conversation

@chuks-qua

@chuks-qua chuks-qua commented Oct 6, 2026 •

Copy link
Copy Markdown
Contributor

What

Since #1779 the server publishes live turn events only on agent.canonical. The runtime live harness and the composer-queue proof still listened for agent.event, so every live scenario timed out with "No terminal provider event arrived" even when the reply was saved.

The harness now reads the publication.recorded payloads of accepted, saved, and recovery frames through canonicalFrameToLiveEvents. It applies the web client's publication route and records each event ID once, because saved and recovery frames repeat accepted events. A stopped turn now publishes only ended with outcome interrupted. So ended counts as completion only with a completed outcome, and counts as a stop otherwise.

A second commit fixes the OpenCode resume restart. It called health 15 seconds after agent:up, which returns before the server is ready. It now waits with agentReady, bounded by the proof deadline.

Verified on a live worktree runtime:

  • opencode-resume with opencode/muse-spark-1.3-contributor-free: ok: true, every resume field true, sdk_session_invalidated seen after the restart.
  • subagent with Codex gpt-5.6-terra on the fixture repo: ok: true, terminalEvent: turnComplete.
  • completion with Claude claude-haiku-4-5: ok: true, terminalEvent: turnComplete.
  • node --test runtime.test.mjs: 14 pass. bun test composer-queue.test.mjs: 58 pass. All test frames parse under CanonicalAgentProgressFrameSchema.

Why

Agents use runtime live to prove provider changes. With every scenario failing for every provider, the harness could not prove anything.

Review Notes

  • stop still fails, at a different step. Both concurrent agent.stop calls now return status: cancelled. hasSharedStopResult expects one cancelled and one already-terminal peer, and it compares results by reference. The push side of stop now works: turnStarted arrives and ended=interrupted is recorded. I left the stop contract alone because I could not tell whether the server or the harness holds the intended behavior.
  • thread.status produced no pushes for a completed or a stopped Claude turn on this runtime. The harness still reads it, but stop detection no longer depends on it.
  • Devin permission and composer-queue proofs were not run live. They use the same intake.

View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

Since #1779 the server publishes live turn events only on the
agent.canonical push channel. The runtime live harness and the
composer-queue proof still listened for agent.event, so every runtime
live scenario timed out waiting for a terminal event even when the
assistant reply was saved.

canonicalFrameToLiveEvents reads the publication.recorded payloads of
accepted, saved, and recovery frames and applies the web client's
publication route. Callers record each event ID once because saved and
recovery frames repeat accepted events. A stopped turn now publishes
only ended with an interrupted outcome, so ended counts as completion
only with a completed outcome and counts as a stop otherwise.
…me restart

agent:up returns after it writes ports.json, before the server answers
health. The resume proof called health with a 15-second budget right
after agent:up and failed when startup took longer. On a loaded host
the server took up to 15.9 seconds to open its listener, Vite once took
19.9 seconds, and one restart also failed the agent:ready CLI's fixed
30-second budget. Call agentReady in-process, bounded by the proof
deadline.
@chuks-qua
chuks-qua merged commit b48d57c into main Oct 6, 2026
6 checks passed
@chuks-qua
chuks-qua deleted the fix/verify-mcode-canonical-live-events branch October 6, 2026 11:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant