Skip to content

fix(agents): report managed runtime readiness - #5980

Open
ugiya wants to merge 1 commit into
block:mainfrom
ugiya:fix/managed-agent-startup
Open

fix(agents): report managed runtime readiness#5980
ugiya wants to merge 1 commit into
block:mainfrom
ugiya:fix/managed-agent-startup

Conversation

@ugiya

@ugiya ugiya commented Aug 15, 2026

Copy link
Copy Markdown

Summary

  • emit ready after successful eager-pool startup while preserving listening for lazy pools
  • persist managed-agent lifecycle frames in observer order instead of launching overlapping Tauri writes
  • stop a stale lifecycle batch after a community/store reset

Problem

Desktop registers a newly spawned managed runtime as starting and waits for owner-private lifecycle telemetry to advance it. buzz-acp emitted 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 -> ready sequence could therefore complete out of order and regress the stored state.

Fix

buzz-acp now emits exactly one startup lifecycle after channel subscriptions and presence setup:

  • eager pool: ready
  • lazy pool: listening

Desktop 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

  • OS: macOS 26.5.1 (25F80), arm64
  • Hardware: Mac16,5, Apple M4 Max
  • Buzz: Desktop debug/development build with a local relay at ws://localhost:3000
  • Harness: OpenCode 1.18.18 launched as /opt/homebrew/bin/opencode acp, eager pool
  • Hermit toolchain: Rust/Cargo 1.95.0, Node 24.15.0, pnpm 11.4.0

Controlled live reproduction

  1. Start the eager managed agent with the pre-fix buzz-acp while keeping its relay, identity, OpenCode configuration, and all unrelated local patches constant.
  2. Observe that it connects, publishes online presence, subscribes to channels, and answers a mention, while Channel members continues to show Waking.
  3. Rebuild buzz-acp with this lifecycle change and restart the same agent.
  4. Observe the startup ready lifecycle 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 onto 78cbffeb6, and revalidated at the exact pushed head below.

Verification

Exact pushed head: 37dc83372

  • cargo test -p buzz-acp: 779 unit tests + 9 lifecycle integration tests passed
  • cargo clippy -p buzz-acp --all-targets -- -D warnings: passed
  • cargo fmt --all -- --check: passed
  • pnpm --dir desktop test: 4,956 passed
  • pnpm --dir desktop typecheck: passed
  • scoped Desktop Biome check: passed
  • repository pre-push gates: branch skew, Desktop check/typecheck/tests, Rust tests, and Desktop Tauri checks all passed

No 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.

Signed-off-by: ugiya <17926591+ugiya@users.noreply.github.com>

@themiguelamador themiguelamador left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 passed
  • cargo clippy -p buzz-acp --all-targets -- -D warnings
  • cargo fmt --all -- --check
  • focused observer lifecycle tests: 3/3 passed
  • full Desktop suite: 4,957/4,957 passed
  • pnpm typecheck
  • pnpm check
  • commit-time Desktop formatting/file-size hook

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.

2 participants