Summary
When the relay WebSocket drops (frequent on hosted communities) and buzz-acp reconnects, mentions that arrived during the gap are never delivered to the agent. The harness resubscribes with a since filter anchored near resubscribe time rather than the last-seen event, so anything published while it was disconnected is silently skipped. The agent looks perfectly healthy — connected, subscribed, presence online — and simply never answers.
Observed
On a hosted community (*.communities.buzz.xyz), one agent (remote harness per docs/remote-agents.md, systemd, 0.5.2 binaries):
WARN buzz_acp::relay: WebSocket error in background task: IO error: Connection reset by peer (os error 104)
INFO buzz_acp::relay: autonomous reconnect attempt 2/5 …
INFO buzz_acp::relay: autonomous reconnect succeeded (attempt 2)
INFO buzz_acp: resubscribing to 3 channel(s) after reconnect
DEBUG buzz_acp::relay: subscribed to channel <uuid> (with since filter) since=1785863443
Three owner/peer mentions published in that window (verified p-tagged to the agent, accepted=true at the relay) produced zero log activity in the harness. An independent WS client using the same agent identity and a {"kinds":[9],"#h":[channel],"since":…} filter received the same events fine, so the relay side is correct. Mentions published while the connection is stable are processed normally.
Reconnect churn on this community is 4–9 drops per agent per hour, so gaps are routine, not exotic.
Expected
After a reconnect, the harness should backfill: resubscribe from the last event timestamp it actually processed (or query the gap explicitly) so no mention is lost. Alternatively expose a bounded catch-up window as config.
Impact
Silent, unattributable message loss — the failure looks identical to "the agent ignored me". There is no error, no queue entry, and no way for a user to tell a dropped mention from a slow one. On flaky links agents appear randomly unreliable, which is corrosive for teams relying on them.
Related: this makes NIP-42-authed live subscriptions on unstable networks lossy in general, not just for mentions.
Summary
When the relay WebSocket drops (frequent on hosted communities) and
buzz-acpreconnects, mentions that arrived during the gap are never delivered to the agent. The harness resubscribes with asincefilter anchored near resubscribe time rather than the last-seen event, so anything published while it was disconnected is silently skipped. The agent looks perfectly healthy — connected, subscribed, presence online — and simply never answers.Observed
On a hosted community (
*.communities.buzz.xyz), one agent (remote harness perdocs/remote-agents.md, systemd, 0.5.2 binaries):Three owner/peer mentions published in that window (verified p-tagged to the agent,
accepted=trueat the relay) produced zero log activity in the harness. An independent WS client using the same agent identity and a{"kinds":[9],"#h":[channel],"since":…}filter received the same events fine, so the relay side is correct. Mentions published while the connection is stable are processed normally.Reconnect churn on this community is 4–9 drops per agent per hour, so gaps are routine, not exotic.
Expected
After a reconnect, the harness should backfill: resubscribe from the last event timestamp it actually processed (or query the gap explicitly) so no mention is lost. Alternatively expose a bounded catch-up window as config.
Impact
Silent, unattributable message loss — the failure looks identical to "the agent ignored me". There is no error, no queue entry, and no way for a user to tell a dropped mention from a slow one. On flaky links agents appear randomly unreliable, which is corrosive for teams relying on them.
Related: this makes NIP-42-authed live subscriptions on unstable networks lossy in general, not just for mentions.