block / block/buzz

Desktop app (Windows) never attempts reconnect to self-hosted relay after disconnect — "Can't reach the relay" persists indefinitely, even after full data reset

Open
#4,878 0 comments 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.