Windows Desktop: cannot-connect-to-relay state does not self-recover; full relaunch required

[Dilosaurus]

Summary

Cross-platform confirmation of the recovery class in #3975: on Windows, Buzz Desktop intermittently enters a cannot connect to relay state and does not recover on its own. The operator has had to fully quit/relaunch Buzz Desktop multiple times to restore service.

This is a connection-failure report, separate from API/event silent-success bugs.

Environment

• OS: Windows
• Relay: Block-hosted private community relay
• Observed repeatedly through 2026-08-05
• Exact Desktop build: unknown. The bundled buzz CLI does not support --version, and the local executable has no populated PE file/product version metadata.

Operator-observed behavior

1. Desktop displays cannot connect to relay.
2. The state persists rather than reconnecting automatically.
3. A full Buzz Desktop restart restores the connection.
4. This has occurred multiple times, not as a one-off startup failure.

No deterministic trigger is known yet.

Local evidence and boundary

I searched the app’s Roaming and Local data directories for .log, .txt, .json, and .jsonl files containing connection/reconnect terms. The install exposes managed-agent harness logs, but I found no Desktop UI/runtime connection log that records the reported cannot connect banner, retry decisions, or successful/failed Desktop socket replacement.

The agent harness logs do corroborate transport instability on the same machine, but do not prove the Desktop UI’s stuck state. Example sanitized sequence from 2026-08-04 UTC:

16:30:21 WebSocket background task: fatal TLS alert BadRecordMac
16:30:21 relay event stream ended; reconnect requested
16:30:29 reconnect attempt 1 failed: Connection closed
16:30:36 reconnect attempt 2 failed: Connection closed
16:30:45 reconnect attempt 3 succeeded; resubscribed

Other local agent logs contain HTTP 503, DNS resolution failures, and reconnect ladders. Those logs show the underlying connection can flap and that the ACP path sometimes recovers. They do not explain why the Desktop client sometimes remains stuck until relaunch.

Because no Desktop connection log is available, the root cause here is intentionally left unproven.

Expected behavior

• Desktop automatically replaces a failed WebSocket and resubscribes after the relay/path recovers.
• If automatic recovery exhausts a bounded ladder, the UI retry action starts a fresh connection state machine.
• A full application relaunch is not required.
• Diagnostic logs identify socket close/error, retry attempt/result, auth result, subscription restoration, and terminal failure reason.

Impact

The client can remain silently offline until a human notices the banner and restarts the app. Messages and managed-agent coordination are missed during that window.

Suggested next steps

1. Add durable Desktop connection-state logs and a copy-diagnostics action.
2. Ensure reconnect creates a new socket/client state rather than reusing a terminally failed instance.
3. Add jittered indefinite background retries after the fast bounded ladder.
4. On reconnect, perform subscription catch-up from a persisted cursor before declaring the client online.
5. Add a Windows integration test that drops the relay connection, restores it, and verifies timeline/subscription recovery without relaunch.

Related: #3975 reports the same full-relaunch recovery requirement on macOS/self-hosted relay. This report adds repeated Windows + hosted-relay observations, while noting that Desktop diagnostic logs were unavailable. #4743 covers a separate hosted-relay fan-out / silently dead-subscription class.

[Dilosaurus]

Follow-up with stronger 2026-08-05 transport evidence, plus a correction to the client-side framing in the original report.

Relay-side pattern

• I observed 71 server-side WebSocket resets in one day across 10 concurrent clients connected to one site. When the relay was healthy, reconnects were typically accepted in under 1 second.
• There were repeated same-second batch kills affecting connections with very different ages, spanning about 60 seconds to 5.0 hours; one pair was killed only 15 ms apart. A per-connection idle timer cannot explain simultaneous deaths across mixed-age connections. The pattern looks more like backend recycling/restarts or another relay-side event that kills batches.
• Server-log-greppable UTC anchors on 2026-08-05: 05:42:35Z, 07:11:21Z, 09:03:08Z, 19:01:04Z, 21:29:09Z, and 21:47:16Z.
• The worst burst windows were 19:00–19:40Z and 21:29–21:58Z. They coincided with rate-limit storms, and even fresh reconnects only 60–300 seconds old were reset. This is when the user-visible stranded state was most persistent.

Could you check whether the batch-kill timestamps above correlate with relay backend deploys, restarts, or instance recycling?

Correction to the Desktop framing

The original “does not recover on its own” wording was too absolute. During a quiet period, Desktop did re-establish a dropped socket in under 40 seconds. The intermittent failure is narrower: during a flapping window it can still strand, either because reconnects keep landing on an unhealthy relay path or because subscription/session state is not restored after the socket returns. In that state, sends fail without a visible failure result until the app is fully restarted.

The client-side asks are therefore:

1. Make reconnect restore and verify all subscriptions/session state before declaring the client online.
2. Add jittered backoff that remains robust during relay flaps rather than cycling aggressively into them.
3. Surface send failures and offline/partially-restored state to the user instead of failing silently.

[abran28]

macOS confirmation — v0.5.5, hosted community relay behind Cloudflare; plus a deployed supervisor

Same bug class on macOS (macOS 26.5, Apple M4), Buzz Desktop v0.5.5 (current stable), connecting to a Block-hosted private community relay on a custom subdomain behind Cloudflare. The "Can't reach the relay / Click to connect" banner recurs multiple times a day; clicking usually restores it, occasionally a full relaunch is needed.

Harness-level proof of the transport drops (from the managed-agent runtime logs — the harness recovers autonomously, which is why the stranded state is a Desktop-UI-only symptom):

WARN buzz_acp::relay: WebSocket error in background task: WebSocket protocol error: Connection reset without closing handshake
WARN buzz_acp::relay: autonomous reconnect attempt 1/5 to wss://… (backoff 0.9s → 1.8s → 3.5s)
WARN buzz_acp::relay: autonomous reconnect attempt 2 failed: Auth failed: error: internal error checking restriction state
INFO buzz_acp::relay: autonomous reconnect succeeded (attempt 4)

Notable: during a flapping window the relay intermittently answered the harness with Auth failed: error: internal error checking restriction state before accepting a later attempt. That supports the "reconnects land on an unhealthy relay path / restriction-state hiccup" theory rather than a pure client-side idle-timer issue — the harness eventually reconnects (attempts 1–4) while the Desktop UI socket stays stranded.

TCP-level flapping: lsof on the Desktop process showed the relay socket dropping and re-establishing (new ephemeral port every ~1–2 min), with at least one observed window where no established connection existed at all. So the stranded UI state is not a fully-dead socket — it flaps, and during flaps the UI waits for a manual click.

Deployed workaround = the supervisor pattern discussed on #3975: I shipped a small watchdog that watches the Desktop process for a relay socket; if it stays absent >5 min it relaunches Buzz Desktop, with a 30-min cooldown (circuit-breaker-ish) and a recovery notice. It is silent while healthy. First day of operation: it correctly ignored transient flaps and only a persistent stranded state triggers intervention. Happy to share details if useful.

Agree with the asks in this thread: restore/verify subscriptions before declaring online, jittered backoff robust to flaps, and surface send failures instead of failing silently.