fix(acp): surface silent turn-end when agent replies but never publishes (#3980) - #4057
Open
iroiro147 wants to merge 1 commit into
Open
fix(acp): surface silent turn-end when agent replies but never publishes (#3980)#4057iroiro147 wants to merge 1 commit into
iroiro147 wants to merge 1 commit into
Conversation
…hes (block#3980) When a buzz-acp-driven agent ends a turn with non-empty agent_message_chunk text but never makes a successful 'buzz messages send' call, the turn ends with zero signal — no relay message, no warning. Desktop's observer view shows a coherent reply while the relay has nothing, so operators can't tell the agent failed to publish. Accumulate streamed agent_message_chunk text per turn and track whether any tool call completed. At every turn boundary (the shared send_prompt_result chokepoint, so all outcomes inherit it), if the turn produced text but completed zero tool calls — i.e. it never shelled out to publish — emit a 'pool::prompt' warning naming the turn, byte count, and a content preview. That surfaces the silent-failure mode in operator logs and Desktop's observer view, closing the visibility gap from the issue. Scope note: this adds the turn-level accumulation + detection + warning. A relay-visible failure notice (via post_failure_notice) requires channel and thread-tag context the shared result chokepoint doesn't carry; wiring that is the deliberate follow-on. No behavior change to publishing itself, no fuzzy matching, and publishing-success agents are untouched (any completed tool call suppresses the warning). Verified: cargo check + cargo test (661+9, matching main baseline) + clippy clean. Refs block#3980 Signed-off-by: iroiro147 <sarthak.singh@juspay.in>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Refs #3980 — surfaces the silent-failure mode when a
buzz-acpagent ends a turn with non-emptyagent_message_chunktext but never makes a successfulbuzz messages sendcall.Today that turn ends with zero signal: no relay message, no warning, no failure notice. Desktop's activity/observer view shows a coherent reply while the relay has nothing, so an operator can't tell the agent failed to publish.
What this does
agent_message_chunktext per turn inAcpClient(unpublished_turn_text), alongside acompleted_tool_call_this_turnflag set by anytool_call_updatewithstatus == "completed".take_unpublished_turn_notice()(public, per-turn) returnsSome(text)only when the turn produced non-empty text and completed zero tool calls — the case where the agent never shelled out tobuzz messages send, so its reply is invisible on the relay. Resets both fields so each turn starts clean.send_prompt_resultchokepoint (so every outcome inherits it), the harness emits apool::promptwarning with the turn id, byte count, and a content preview. That makes the silent-failure mode visible in operator logs and Desktop's observer view.Scope (deliberately bounded)
This adds turn-level accumulation + detection + a warning. A relay-visible failure notice (via
post_failure_notice) is the natural follow-on but is not in this PR: that path needschannel_id+ thread tags at the publish site, which the shared result chokepoint doesn't carry, and wiring it without that context risks leaking or wrong-channel posts. The accumulation state introduced here is exactly what that follow-on consumes.Publishing itself is unchanged; agents that complete any tool call (the publish path) never trigger the warning. No fuzzy matching introduced.
Verification
cargo check -p buzz-acp— cleancargo test -p buzz-acp— 661 + 9 passing (matchesmainbaseline, no regression)cargo clippy -p buzz-acp— clean