[Bug] Hosted relay intermittently stalls desktop message loading and disconnects

[plantbob0101]

Describe the bug
Buzz Desktop 0.5.4 intermittently takes several seconds to load messages and surfaced a relay-disconnected state on a hosted *.communities.buzz.xyz workspace. The Mac and app are otherwise idle. Direct probes isolate the delay to the hosted relay/WebSocket path rather than the local network or renderer CPU.

Steps to reproduce

1. Open Buzz Desktop against a hosted *.communities.buzz.xyz workspace.
2. Switch to a DM/channel and wait for messages to load.
3. Observe multi-second loading and occasional relay disconnect.
4. Probe the same relay from the same Mac:
   • Ten HTTPS relay-information requests: TTFB ranged 0.720–4.705 s.
   • Ten WebSocket REQ probes: connection/query completion ranged 0.778–4.307 s; two connection errors and one 10 s timeout.
   • /health remained fast at 0.109 s.

Expected behavior
Existing messages load promptly, WebSocket subscriptions stay connected, and relay responses do not intermittently take multiple seconds or time out.

Version and platform

• Buzz Desktop: 0.5.4 (0.5.4), current latest release as of 2026-08-04
• OS: macOS 27.0 (26A5388g), Apple silicon
• Relay: hosted *.communities.buzz.xyz (specific workspace omitted because the report is public)

Logs / additional context
Evidence captured 2026-08-04 around 10:00 America/Los_Angeles:

• Local network was healthy: base RTT ~40 ms, download throughput ~73.8 Mbps.
• Relay TCP/TLS setup was fast (~20–38 ms TCP, ~36–203 ms TLS); the delay accrued after TLS while waiting for the relay/application response.
• Buzz desktop process was idle (~0% CPU); WebContent was ~0.4–0.8% CPU during sampling.
• Relay /health returned 200 in 0.109 s while the NIP-11/root route took 3.066 s in the same probe set.
• App restart did not prevent recurrence; the reported slowdown occurred roughly seven minutes after a fresh 0.5.4 launch.

This points to an intermittent hosted relay/application-path latency or subscription-recovery issue, not a proven desktop rendering bug. Please inspect hosted relay request/subscription latency and desktop reconnect behavior together.

[jeyarajcs]

Describe the bug Buzz Desktop 0.5.4 intermittently takes several seconds to load messages and surfaced a relay-disconnected state on a hosted *.communities.buzz.xyz workspace. The Mac and app are otherwise idle. Direct probes isolate the delay to the hosted relay/WebSocket path rather than the local network or renderer CPU.

Steps to reproduce

1. Open Buzz Desktop against a hosted *.communities.buzz.xyz workspace.

2. Switch to a DM/channel and wait for messages to load.

3. Observe multi-second loading and occasional relay disconnect.

4. Probe the same relay from the same Mac:

   • Ten HTTPS relay-information requests: TTFB ranged 0.720–4.705 s.
   • Ten WebSocket REQ probes: connection/query completion ranged 0.778–4.307 s; two connection errors and one 10 s timeout.
   • /health remained fast at 0.109 s.

Expected behavior Existing messages load promptly, WebSocket subscriptions stay connected, and relay responses do not intermittently take multiple seconds or time out.

Version and platform

• Buzz Desktop: 0.5.4 (0.5.4), current latest release as of 2026-08-04
• OS: macOS 27.0 (26A5388g), Apple silicon
• Relay: hosted *.communities.buzz.xyz (specific workspace omitted because the report is public)

Logs / additional context Evidence captured 2026-08-04 around 10:00 America/Los_Angeles:

• Local network was healthy: base RTT ~40 ms, download throughput ~73.8 Mbps.
• Relay TCP/TLS setup was fast (~20–38 ms TCP, ~36–203 ms TLS); the delay accrued after TLS while waiting for the relay/application response.
• Buzz desktop process was idle (~0% CPU); WebContent was ~0.4–0.8% CPU during sampling.
• Relay /health returned 200 in 0.109 s while the NIP-11/root route took 3.066 s in the same probe set.
• App restart did not prevent recurrence; the reported slowdown occurred roughly seven minutes after a fresh 0.5.4 launch.

This points to an intermittent hosted relay/application-path latency or subscription-recovery issue, not a proven desktop rendering bug. Please inspect hosted relay request/subscription latency and desktop reconnect behavior together.

I am facing the same.. Especially in the last few hours

[air3ijai]

• relay: post-OOM silent permanent crashloop — pre-bind fleet-wide NIP-43 sweep exceeds 120s startup probe at 42k communities #4555
• relay: per-pod anon memory staircase to 10Gi OOMKill every 24-48h — migrating singleton 'carrier' role, ~173x anon-per-wire-byte amplification #4556

[gra-kir]

I’m seeing what appears to be the same underlying issue on macOS with Buzz Desktop v0.5.4.

Additional symptoms I’m seeing that may help narrow it down:

• Managed Claude agents initially work correctly.
• After some time they begin hanging and stop responding.
• The harness logs show buzz-acp starts successfully, creates the agent pool, connects to the relay and subscribes to channels without authentication errors.
• My local Claude Code installation remains fully functional (claude -p works normally).
• I intermittently receive:
  • relay returned 500 Internal Server Error
  • followed later by:
    relay returned 404 Not Found: relay: no community is configured for this host
• Restarting the app and agents does not permanently resolve it.

This suggests the issue may be in the hosted relay/community layer rather than Claude authentication.

Happy to provide harness logs if they’re useful.

[niklaskie]

We run a self-hosted relay (image ghcr.io/block/buzz:sha-9cc9652, deployed Jul 24) for a small team (4 humans + several ACP agents) and see what looks like the same problem, with some server-side data that may help triage.

Symptoms (matching OP): desktop clients intermittently can't send messages (messages appear sent locally but never arrive), connections drop, users work around it by fully quitting and reopening the app. Mobile shows the same pattern.

Server-side evidence (relay logs, last 48h), connections per authenticated pubkey:

client	connections	median duration	>10 min
user A	1,496	1.3 s	5
user B	299	1.8 s	4
user C	112	90 s	9
user D (healthy)	16	35 min	8
agent (buzz-acp)	1	23 h	1

Three of four human clients almost never hold a connection. The repeating pattern for the affected clients, cycling every ~30 s for hours:

WebSocket connection established
NIP-42 auth successful          (same pubkey)
WebSocket connection closed     (<1 s after successful auth)

Additionally over 7 days: 702× 3 missed pongs — closing connection (~100/day) and 38× NIP-42 auth timeout — closing connection (5 s timeout).

Confirmed message loss: one affected user reported "can't send"; the relay DB shows exactly one kind-9 event from their pubkey in that session and nothing afterwards — and the relay logged zero event rejections on the WS path in 7 days. Whatever the client showed as "sent" never reached the relay.

Probably not the network path: the relay sits behind a Cloudflare tunnel, but the one healthy desktop client (user D) and all long-lived agent connections go through the same tunnel and edge.

Happy to provide full logs or run instrumented tests against our deployment if useful.