fix(relay): log event kind on accepted /events bridge requests - #4719
Open
subashmokshya wants to merge 1 commit into
Open
fix(relay): log event kind on accepted /events bridge requests#4719subashmokshya wants to merge 1 commit into
subashmokshya wants to merge 1 commit into
Conversation
Typing indicators (kind 7) and their deletions (kind 5) travel the same /events route as real messages (kind 9), but the HTTP bridge's terminal attribution line logged only `accepted`, not `kind`. Every agent turn therefore produced `accepted:true` lines whether or not a message was actually sent, making a silent no-op indistinguishable from a real send without querying Postgres directly. Thread the already-computed `kind_u32` through `SubmitOutcome::Ok` and add it to the info! attribution line. The Rejected arm already logs `kind`; this closes the gap on the accepted arm. Fixes block#4676 Signed-off-by: Subash <117739368+subashmokshya@users.noreply.github.com>
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
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.
What
The relay's HTTP bridge terminal attribution line for an accepted event logs
acceptedbut notkind:{"pubkey":"d5b0ab11…","route":"/events","status":200,"accepted":true,"...":"HTTP bridge request"}Typing indicators (kind 7) and their deletions (kind 5) travel the same
/eventsroute as real messages (kind 9), so every agent turn producesaccepted:truelines whether or not a message was actually sent — a silent no-op is indistinguishable from a real send without querying Postgres directly. This has misled at least two separate debugging sessions (see #4676).Change
kind_u32is already computed insubmit_event_authedbefore ingest. This PR threads it through theSubmitOutcome::Okvariant and adds it to theinfo!attribution line. TheRejectedarm already logskind; this closes the gap on the accepted arm.Now an accepted message vs. an accepted typing indicator are distinguishable at a glance:
Scope kept intentionally minimal (kind only). The issue also mentions
channel_idas a "nice to have"; happy to add it in a follow-up if wanted — it needs thehtag extracted before the event is moved intoingest_event, so it's a slightly larger change than this one-field fix.Verification
cargo check -p buzz-relay— cleancargo clippy -p buzz-relay -- -D warnings— cleancargo fmt --check— cleanTesting note
The existing attribution tests (
submit_event_invalid_json_…,submit_event_relay_only_kind_…) cover the ParseFail and Rejected arms and remain green — this change doesn't touch them. There is no dedicated Ok/accepted-arm attribution test; adding one requires a member pubkey + valid channel event against a live Postgres (the#[ignore = "requires Postgres"]tier). I'm glad to add aT3casserting the accepted line carrieskind=if you'd like it in this PR.Fixes #4676
Developed with AI assistance (Claude Code); reviewed and verified locally by me.