Desktop app (Windows) never attempts reconnect to self-hosted relay after disconnect — "Can't reach the relay" persists indefinitely, even after full data reset
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
Summary:
After the relay's underlying server was rebooted (dropping the app's live WebSocket), the windows desktop client shows a persistent "Can't reach the relay / Click to connect" banner. Clicking it never actually attempts a new connection. This persists across an app version update and a complete wipe of the app's local data (both %APPDATA%\xyz.block.buzz.app and %LOCALAPPDATA%\xyz.block.buzz.app, including the WebView2 profile).
Diagnostic steps taken (all point at the desktop client specifically):
- Relay confirmed healthy and externally reachable (/_liveness → 200 ok) from the same machine, at the same time the app shows the error.
- Raw WebSocket handshake to the relay's ws:// endpoint from the same machine succeeds (ClientWebSocket → State: Open).
- The official buzz.exe CLI, from the same machine, connects to the same relay successfully (buzz.exe channels list → exit 0, valid JSON response).
- Relay's own application logs (which correctly capture real connections, confirmed via a genuine successful login earlier in this session) show zero connection attempts during multiple "Click to connect" clicks — not a rejected/failed handshake, no attempt at all.
- Get-NetTCPConnection on the client machine, polled continuously during clicks, shows zero outbound connection attempts to the relay's IP/port.
- Removing/re-adding BUZZ_RELAY_URL has no effect on the symptom either way — app appears to have cached the relay connection internally after - the first successful login and no longer depends on the env var, but also never retries it.
- Updating desktop app v0.5.4 → v0.5.5: no change.
- Full reset of local app state (quit, delete %APPDATA%\xyz.block.buzz.app and %LOCALAPPDATA%\xyz.block.buzz.app, relaunch as fresh first-run): same symptom.
- No firewall rule, Windows Defender detection/block, or third-party AV/EDR process found referencing the app.
**Expected behavior**
clicking "Click to connect," or relaunching the app, should re-attempt the WebSocket connection to the configured relay.
**Version and platform**
OS: Windows 10 Enterprise
Buzz Desktop: v0.5.4 → reproduced again after updating to v0.5.5
Relay: self-hosted, deployed via deploy/compose, plain ws://, BUZZ_REQUIRE_AUTH_TOKEN=false, BUZZ_REQUIRE_RELAY_MEMBERSHIP=false
Connected via BUZZ_RELAY_URL env var (per README) to skip the default Builderlab onboarding
Conclusion: the relay, network path, and Buzz's own client protocol code (proven via the CLI) are all functioning correctly. The bug appears isolated to buzz-desktop.exe's (Tauri/WebView2) reconnect state machine on Windows — the UI's "Click to connect" action does not trigger any underlying network attempt.
Contributor guide
Assessment
This issue has not been assessed yet.