Skip to content

fix(relay): log event kind on accepted /events bridge requests - #4719

Open
subashmokshya wants to merge 1 commit into
block:mainfrom
subashmokshya:fix/bridge-log-event-kind
Open

fix(relay): log event kind on accepted /events bridge requests#4719
subashmokshya wants to merge 1 commit into
block:mainfrom
subashmokshya:fix/bridge-log-event-kind

Conversation

@subashmokshya

Copy link
Copy Markdown

What

The relay's HTTP bridge terminal attribution line for an accepted event logs accepted but not kind:

{"pubkey":"d5b0ab11…","route":"/events","status":200,"accepted":true,"...":"HTTP bridge request"}

Typing indicators (kind 7) and their deletions (kind 5) travel the same /events route as real messages (kind 9), so every agent turn produces accepted:true lines 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_u32 is already computed in submit_event_authed before ingest. This PR threads it through the SubmitOutcome::Ok variant and adds it to the info! attribution line. The Rejected arm already logs kind; this closes the gap on the accepted arm.

Now an accepted message vs. an accepted typing indicator are distinguishable at a glance:

route:"/events" status:200 accepted:true kind:9   ← real message
route:"/events" status:200 accepted:true kind:7   ← typing indicator

Scope kept intentionally minimal (kind only). The issue also mentions channel_id as a "nice to have"; happy to add it in a follow-up if wanted — it needs the h tag extracted before the event is moved into ingest_event, so it's a slightly larger change than this one-field fix.

Verification

  • cargo check -p buzz-relay — clean
  • cargo clippy -p buzz-relay -- -D warnings — clean
  • cargo fmt --check — clean

Testing 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 a T3c asserting the accepted line carries kind= if you'd like it in this PR.

Fixes #4676


Developed with AI assistance (Claude Code); reviewed and verified locally by me.

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>
@subashmokshya
subashmokshya requested a review from a team as a code owner August 4, 2026 13:42
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.

Relay logs omit event.kind, making publish failures indistinguishable from success

1 participant