Buzz Desktop managed-agent publisher replays stale signed kind:30177 events indefinitely

[unclesvf]

We run a self-hosted Buzz relay (ghcr.io/block/buzz:main) with one Buzz Desktop client (0.5.4 per the client's binary version resource and uninstall registry; Windows). The desktop's managed-agent re-assert loop republishes the signed kind:30177 event persisted at instance creation instead of re-signing, so once that artifact ages past the relay's ±900s ingest window, every re-assert is rejected — permanently, every 30 seconds, with no recovery path. Measured on our relay: 15,462 rejected writes across a 47-hour log window (a floor — the storm predates the window), about a third of the client's bridge traffic, and no agent-definition update can reach the relay again.

Full diagnosis below: mechanism with timestamps, a reproduction that needs only an agent and fifteen minutes of waiting, and a suggested fix — re-sign at publish, and invalidate the retained artifact on rejection. Cross-verified independently from the relay side and the client host.

---

Buzz Desktop: managed-agent publisher replays a stored signed event instead of re-signing

Status: diagnosis complete, cross-verified from both sides (relay + client host).
Written: 2026-08-05. Investigators: Calliope (relay side, Delphi), Athena (client side, Aurora).
Intended use: upstream bug report to the Buzz maintainers.

---

Summary

Buzz Desktop's managed-agent publisher re-asserts each agent definition by
republishing the signed kind:30177 event it stored on first publish, rather
than re-signing at publish time. Because a Nostr event id commits to
created_at, the artifact's timestamp never moves. Once the stored event ages
past the relay's ingest window (±900s), every subsequent re-assert is rejected —
permanently, on a 30-second cycle, with no path to recovery short of deleting
the artifact.

A rejection does not trigger a re-sign, so the loop is closed: the definition
can never be updated on the relay again, and the client never learns.

Impact, measured

Measured on one relay (Delphi, ghcr.io/block/buzz:main) against one desktop:

Metric	Value
Rejected writes in retained log window (2026-08-03T21:32Z → 2026-08-05T20:56Z, 47.4h)	15,462 as of 2026-08-05T20:56Z — still climbing at the rate below
Rate while the client is running	360/hour — exactly 3 events per 30s cycle
Average across the window	326/hour — the shortfall is client downtime, not a varying rate (see below)
Share of all HTTP bridge traffic in a sample hour	360 of 1,125 requests (32%)
Stored kind:30177 rows, all time	6 — three from 2026-07-30, three from 2026-08-02. None since.
Storm began	~2026-08-03T00:15Z — 15 minutes after signing, when the artifact aged past the window

Every rejection is a full request: TLS, auth, signature verification, and a
WARN log line, discarded at the timestamp gate
(MAX_TIMESTAMP_DRIFT_SECS = 900, crates/buzz-relay/src/handlers/ingest.rs).
The relay has accepted no managed-agent definition from this client since
2026-08-02T23:59Z.

The retained log window opens after the storm began, so 15,462 is a floor, not
a total.

The cadence never adapts. Scanning the whole retained log for interruptions
in the rejection stream — threshold set at 45s, i.e. any single missed 30s cycle
— finds ten, of which two are substantial and both fall on 2026-08-04:

07:29:02Z → 11:43:01Z   4.23 h    client host rebooted (Windows Update); the
                                  desktop does not auto-start
11:43:01Z → 11:48:55Z   5.9 min   app restart cycle immediately after

The other eight are isolated one-or-two-cycle skips of 47–74s, scattered across
the three days, each followed immediately by a return to the exact 30s cadence.
Three of them cluster in the 12:07–12:27Z hour on 08-04, the tail of that
morning's restart sequence.

The distinction that matters for diagnosis: none of these is backoff. A
client reacting to rejection would show growing intervals; these are flat ~60s
one-offs against an otherwise metronomic 30s, with no trend in either
direction. The 4.23h reboot accounts for the difference between the 360/hour
running rate and the 326/hour window average. Nothing in the client ever slows
down, backs off, or gives up: ~15,000 identical rejections have produced no
change in its behaviour at all.

Client build version is not recorded here because the relay does not log a
client version or user-agent on this path — anyone citing one should source it
from the desktop host.

Reproduction

1. Create a managed agent in Buzz Desktop; observe the kind:30177 event publish
   and be accepted.
2. Wait longer than the relay's ingest window (15 minutes).
3. Observe every subsequent 30-second re-assert rejected with
   invalid: event timestamp too far from server time, indefinitely.

No further action is required to reproduce — step 2 is just waiting.

Mechanism, established

1. Definitions are signed once, at instance creation. On 2026-08-02 the
   three agents' store entries were written at 23:59:48.663, .775, .880,
   and the resulting events carry created_at of 1785715188, 1785715189,
   1785715189 — that is, :48, :49, :49.

   All three entry stamps fall inside second :48, so the event stamp is not
   derived from the entry field: truncation would give :48,:48,:48 and
   rounding :49,:49,:49. Neither reproduces the observed split. What does fit
   is signing with now() shortly after each entry write, with the run crossing
   the second boundary between the first and second agent — consistent with any
   write-to-sign delay between roughly 0.23s and 0.34s. The delay is inferred
   from that constraint, not measured; the load-bearing conclusion is only
   that the stamp comes from signing time, not from a stored field.

2. The signed event is persisted verbatim.
   %APPDATA%\xyz.block.buzz.app\agents\retention\<uuid>.db — SQLite, mtime
   frozen at 2026-08-03T00:00:00Z (~11s after signing, i.e. after the relay
   accepted), untouched since. It holds complete signed events — id, sig,
   created_at, tags, content — plus the serialized projection string used
   as the change comparator.

3. The periodic re-assert replays that artifact unconditionally. Publish
   success was recorded on 08-02, and the projection has not changed, yet the
   client still re-asserts every 30 seconds — so this is not merely
   "suppression keyed to a success that never arrives." It replays regardless,
   and a rejection never marks the artifact stale.

4. Nothing else can move the timestamp. App restarts do not (three on
   08-04). Local store edits do not — they touch updated_at, not the stored
   event. A UI edit would not either: it changes content, but the publisher
   still replays the retained artifact.

Cross-verification

The two sides were checked independently and agree exactly:

• Relay-side: the three stored rows' NIP-01 ids recompute from their own fields
  (sha256([0,pubkey,created_at,kind,tags,content])) — all three match.
• Client-side: today's live store values, run through the documented
  agent_event_content() projection, reproduce the stored content strings
  byte-for-byte and therefore the same three ids.
• The retention DB's stored event for Fizz matches the relay's stored row field
  for field, including the omitted respond_to_allowlist key on an empty vec.

So the client is emitting a byte-identical event with a byte-identical id every
cycle, and has been for three days.

Note on the payload projection

ManagedAgentEventContent declares nine fields, but
agent_event_content() (desktop/src-tauri/src/managed_agents/agent_events.rs)
nulls system_prompt, model, provider and persona_source_version whenever
persona_id.is_some() — the documented "slimmed projection" — and all four are
skip_serializing_if = "Option::is_none". Definition-linked instances
therefore emit exactly five fields. This is recorded because a struct-shape
reading of the binary suggests nine and leads to the wrong conclusion.

Suggested fix

Re-sign at publish time. The re-assert path should build and sign a fresh
event with now() rather than replaying the retained artifact; the retention
row should serve as the change comparator (its evident purpose) and not as the
thing that gets sent.

Secondary, defence in depth: a rejected publish should invalidate the retained
artifact so the next cycle re-signs, rather than replaying it indefinitely.

Local workaround (untested, destructive-ish)

Full app quit including tray → rename the retention DB → relaunch, expecting the
publisher to find no artifact and sign fresh. Reversible by renaming back.
Rebuild behaviour is unproven. Not run: the fix belongs upstream, and this
touches app data.

Do not attempt to fix it by editing managed-agents.json created_at — the
publisher does not read that field for the event stamp.

Relay-side mitigation (optional, does not fix the client)

At the ingest timestamp gate (crates/buzz-relay/src/handlers/ingest.rs), a
verbatim re-send of an event the relay already stores could be answered
duplicate: instead of invalid:. Verified applicable: the ids are stable, so
the lookup would match.

Two caveats: put the lookup inside the rejection branch, not before the
gate, so normal ingest pays no extra database round-trip; and note that this
silences the only signal that surfaces the client defect. It should not be
treated as closing this report.

[harveysamuel99]

文档写得很友好，感谢开源 ⭐✨

[wellsashley00]

✨👍🧠 代码风格统一，review 压力小

[unclesvf]

Workaround confirmation — mechanism verified end-to-end on the affected host.

We parked the retained artifact while the app was fully quit (renamed %APPDATA%\xyz.block.buzz.app\agents\retention\<uuid>.db aside), then relaunched:

• App start 22:14:15Z → all six managed-agent definitions (three agents × two relay eras) re-signed with fresh created_at at 22:14:17Z — accepted by the relay on the first cycle.
• The rejection storm stopped dead: counter frozen at 15,789 from 22:11:41Z onward, zero rejections since, app confirmed up throughout.
• The app rebuilt a fresh retention DB at the same path ~30s later (22:14:46Z) containing the newly signed events.

This confirms the diagnosis exactly: the publisher re-signs immediately and correctly the moment the stale retained artifact is out of the way — the artifact replay is the sole defect, and invalidating it (per the suggested fix) resolves the storm and restores definition updates.