fix(acp): log inbound author-gate drops at info, with event id and kind - #6466
Open
Cynthia427 wants to merge 1 commit into
Open
fix(acp): log inbound author-gate drops at info, with event id and kind#6466Cynthia427 wants to merge 1 commit into
Cynthia427 wants to merge 1 commit into
Conversation
The author gate's drop was the only signal that an event addressed to this agent was rejected — and it logged at debug, so any deployment running at info saw nothing. A mis-scoped respond_to, a workflow message signed by an unexpected key, or a revoked sibling all presented as the agent silently ignoring a mention, indistinguishable from a stalled session until someone attached a debugger. Running agent fleets against a relay we have paid for this twice: a scheduled workflow's send_message wake-ups died at this gate for days (the relay-signed events were neither owner nor sibling), and a mis-scoped allowlist read as an unresponsive agent. Both diagnoses required reproducing the drop under a debug build; both would have been one grep at info. Promote the line to info and add event_id and kind so a single log line identifies exactly which event died and why. Drops here are rare and attacker-uncontrolled in practice (the gate fires on configuration mismatches, not floods), so log volume is not a concern; if a deployment disagrees, filtering one targeted line down is trivial — reconstructing an invisible drop is not. Signed-off-by: Cynthia Rohr <cynthia.r@kreativreason.co>
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.
Problem
When
author_allowedrejects an inbound event, the drop logs atdebug— so a deployment running at the defaultinfolevel sees nothing at all. The gate is the only place this rejection is observable: there is no sender feedback and no counter. In practice that means a mis-scopedrespond_to, a workflow message signed by an unexpected key (see the #6129/#6311 history — the silent death of workflow wake-ups at this exact gate is what made that bug take days to find), or a revoked sibling all present identically: the agent appears to ignore a mention, indistinguishable from a stalled session.Running agent fleets against a Buzz relay, we have paid this invisibility tax twice — both diagnoses required reproducing the drop under a debug build, and both would have been a single grep at info.
Change
Promote the drop line to
infoand addevent_idandkindto the structured fields, so one log line identifies which event died at the gate and under which mode. A comment at the site records why info is the deliberate level.Volume note: drops here fire on configuration mismatches, not message floods — the line is rare in a healthy deployment. Filtering a targeted line down is trivial for anyone who disagrees; reconstructing an invisible drop is not.
Validation
cargo check -p buzz-acpclean on currentmain; the change is a log statement only, no behavior change.