A turn can complete "successfully" while the agent's reply is silently lost: if the agent's buzz messages send fails (observed: auth error, exit 3), the harness sees end_turn with outcome=ok, fires no failure notice, and requeues nothing. The human sees a mention with no response and no indicator.
Observed live (local relay, buzz-acp with claude-code-acp, kind:9 mention):
INFO acp::stream: …ails with an auth error (exit 3). The answer to the question is **14**, but I have no way to post it to the channel until…
INFO pool::prompt: turn complete for channel 85453cd6-…: end_turn
DEBUG buzz_acp: agent_returned agent=0 outcome="ok"
The agent computed the answer, reported its inability to post in its final text, and the harness treated the turn as ok — the failure classification from #1659/#2289 doesn't catch it because the ACP turn itself didn't error; only the out-of-band CLI write did.
What triggered the auth failure here is unconfirmed (transient; same env posted successfully in adjacent turns). The report is about the missing recovery path, not the auth error itself:
- The harness has no signal that a turn which was supposed to reply actually published anything. A cheap heuristic: turn ended
ok + zero relay OKs for agent-authored channel events during the turn + triggering event was a mention → emit the existing failure notice (or retry once).
- Alternatively, surface CLI write failures back into the turn outcome so the existing dead-letter path applies.
Can take a PR for either direction if maintainers have a preference.
A turn can complete "successfully" while the agent's reply is silently lost: if the agent's
buzz messages sendfails (observed: auth error, exit 3), the harness seesend_turnwithoutcome=ok, fires no failure notice, and requeues nothing. The human sees a mention with no response and no indicator.Observed live (local relay, buzz-acp with
claude-code-acp, kind:9 mention):The agent computed the answer, reported its inability to post in its final text, and the harness treated the turn as ok — the failure classification from #1659/#2289 doesn't catch it because the ACP turn itself didn't error; only the out-of-band CLI write did.
What triggered the auth failure here is unconfirmed (transient; same env posted successfully in adjacent turns). The report is about the missing recovery path, not the auth error itself:
ok+ zero relay OKs for agent-authored channel events during the turn + triggering event was a mention → emit the existing failure notice (or retry once).Can take a PR for either direction if maintainers have a preference.