fix(agents): report managed runtime readiness - #5980
Conversation
Signed-off-by: ugiya <17926591+ugiya@users.noreply.github.com>
themiguelamador
left a comment
There was a problem hiding this comment.
Reviewed head 37dc8337255a3ffcfd7c4e454b7dbc01d4bfd8ab.
I found one blocking ordering bug in the Desktop half of the change. The observer live subscription deliberately replays the last five minutes, while relay queries return stored events newest-first (created_at DESC). On reconnect, a prior waking → ready transition therefore arrives as ready → waking. Awaiting lifecycle writes in delivery order makes that replay deterministically leave the runtime in the stale Waking state—the same symptom this PR is intended to fix.
The regression and fix are in 01c36e3a7 on Complear:review/pr-5980-fix. It records the highest successfully applied observer sequence per runtime pair and start nonce, so older replay frames are ignored while a new process generation can restart its sequence. I also corrected the new test fixture from the non-production relay_url shape to the actual relayUrl/startNonce observer payload and added a newest-first replay test.
Verification on the exact reviewed head plus fix:
cargo test -p buzz-acp: 779 unit tests + 9 lifecycle integration tests passedcargo clippy -p buzz-acp --all-targets -- -D warningscargo fmt --all -- --check- focused observer lifecycle tests: 3/3 passed
- full Desktop suite: 4,957/4,957 passed
pnpm typecheckpnpm check- commit-time Desktop formatting/file-size hook
Summary
readyafter successful eager-pool startup while preservinglisteningfor lazy poolsProblem
Desktop registers a newly spawned managed runtime as
startingand waits for owner-private lifecycle telemetry to advance it.buzz-acpemitted the startup lifecycle only for lazy pools (listening), so an eagerly initialized harness could be online, subscribed, and answering messages while Desktop permanently rendered it as Waking.Lifecycle frames were also written with fire-and-forget Tauri calls. A rapid
waking->readysequence could therefore complete out of order and regress the stored state.Fix
buzz-acpnow emits exactly one startup lifecycle after channel subscriptions and presence setup:readylisteningDesktop awaits lifecycle writes inside its existing observer event queue. Generation checks after the async boundary prevent a batch from resuming into a newly reset community store.
Reproduction environment
25F80),arm64Mac16,5, Apple M4 Maxws://localhost:3000/opt/homebrew/bin/opencode acp, eager poolControlled live reproduction
buzz-acpwhile keeping its relay, identity, OpenCode configuration, and all unrelated local patches constant.buzz-acpwith this lifecycle change and restart the same agent.readylifecycle persist and Channel members change to Here.The live before/after was performed in a worktree based on
69107dc3b; the focused PR was then isolated, rebased onto78cbffeb6, and revalidated at the exact pushed head below.Verification
Exact pushed head:
37dc83372cargo test -p buzz-acp: 779 unit tests + 9 lifecycle integration tests passedcargo clippy -p buzz-acp --all-targets -- -D warnings: passedcargo fmt --all -- --check: passedpnpm --dir desktop test: 4,956 passedpnpm --dir desktop typecheck: passedNo matching open issue or PR was found for the eager startup lifecycle omission or the lifecycle-write ordering race. This changes status behavior only; it does not alter layout or styling.