fix(relay-reconnect): resilient reconnect with fast-path, escalation, and polling

[wpfleger96]

Problem

The relay reconnect button had three compounding failure modes:

Symptom 1 — instant false-fail during Okta sign-in for Block-internal users: warp-cli debug access-reauth exits in ~0.1s (it just opens a browser tab). The ready probe matched Connected on the tunnel (which stays up during Access reauth), so the hook returned immediately — then preconnect() hit the still-blocked network and failed. The user saw a 'Reconnect failed' toast while still mid-login.

Symptom 2 — false-fail after actual reconnect: A single 15s Promise.race on preconnect() determined the verdict. Since preconnect() sets keepAliveRequested=true, the session's background retry loop kept running and often succeeded right after the toast fired — leaving messages flowing in with a 'failed' toast still on screen.

Symptom 3 — spurious browser tab on transient blips: The hook ran unconditionally. A brief wifi dropout that didn't require reauth would still run the internal release's hook and pop a Cloudflare Access tab.

All three mechanisms verified hands-on (see investigation thread).

Solution

Restructure useReconnectRelay into a three-phase strategy:

Phase 1 — fast path: Attempt relayClient.preconnect() with a short 4s timeout. For transient network blips where WARP is already healthy, this succeeds immediately — no hook fires, no browser tab, reconnect is nearly instant.

Phase 2 — escalation (hook-configured builds only): Only if the fast path fails and relay_reconnect_hook_configured() returns true, run the transport-layer hook steps. The hook returns fast (~0.1s); the browser tab opening is the async part of the work.

Phase 3 — poll-until-connected: Retry preconnect() every 3s and watch the connection-state emitter directly. The moment the relay is reachable (Okta completed, or network recovered), the next poll or emitter event declares success — success preempts the backstop regardless of how long login takes. A 120s backstop fires a soft toast() (not toast.error) if polling never succeeds; keepAliveRequested keeps the background retry loop alive after that.

Verdict is now state-driven (connection-state emitter at connected) rather than promise-driven.

Changes

Rust (OSS-clean, no Block-specific code):

• Adds relay_reconnect_hook_configured() -> bool Tauri command — returns option_env!(BUZZ_DESKTOP_BUILD_RELAY_RECONNECT_CMD).is_some(). Registered in lib.rs. The existing relay_reconnect_hook command is unchanged.

TypeScript:

• useReconnectRelay.ts — full redesign to three-phase strategy. Exposes isWaitingForSignIn: boolean for UX copy.
• ConnectionBanner.tsx — shows "Waiting for sign-in…" button label while in phase 3 post-escalation.
• useSidebarRelayConnectionCard.ts — threads isWaitingForSignIn through to card.
• SidebarRelayConnectionCard.tsx — accepts optional isWaitingForSignIn prop; shows "Waiting for sign-in" in title/description when set.
• AppSidebar.tsx — passes isWaitingForSignIn to SidebarRelayConnectionCard.
• e2eBridge.ts — adds relay_reconnect_hook_configured case returning false.
• useReconnectRelay.test.mjs — 10 new unit tests covering all phases.

OSS boundary: No WARP, Okta, or Cloudflare strings in any user-facing copy or runtime code path. The phase 2 escalation only fires when relay_reconnect_hook_configured returns true (internal builds only). "Waiting for sign-in…" copy is generic and only shown in hook-configured builds.

Test results

• 1475/1475 pnpm test passing (includes 10 new tests)
• just desktop-check (biome + file-size gates) clean
• just desktop-typecheck (tsc) clean
• No Block-specific strings in diff: rg -i "warp|okta|cloudflare" desktop/src clean for all new/modified lines

---

Related: squareup/buzz-releases#48 — drops the vestigial ready probe from the baked config (depends on this PR)

[wesbillman]

Two blocking correctness issues:

1. relayReconnectController.ts:197-220 — synchronous connection-state delivery leaks the phase-3 machinery after success. RelayClientSession.subscribeToConnectionState() immediately invokes its listener with the current state. If recovery lands after the fast-path failure/hook but before this subscription, the callback calls finish() synchronously, before unsubscribeConnectionState receives the returned cleanup and before the interval/backstop are installed. Execution then continues and installs both timers even though the controller already finished. The interval remains alive for the app lifetime (its callback only no-ops because resolved is true), and the connection-state subscription is never removed. I reproduced this against the production controller with a synchronously emitted connected: onSuccess=1, state idle, but one interval and one subscription remain. Subscribe/install timers in an order that cannot schedule work after synchronous success, and add this immediate-current-state case to the controller tests.

2. ProfileStep.tsx:80-103 + relayReconnectController.ts:222-223 — onboarding never records an eventual phase-3 reconnect as success. start() intentionally returns false as soon as polling begins, and runConnectivityAction interprets exactly false as “do not call markSuccess().” The controller can later reconnect and clear its shared pending state, but this component has no connection-state subscription or completion callback, so its original save error card remains in the failure state (and becomes clickable again) while the relay is healthy. The sidebar has separate connection-state success handling; onboarding needs equivalent eventual-success handling or a completion contract from the controller.

Validation: local desktop unit suite passes 1496/1496; CI is green. The first issue was additionally reproduced with a focused production-controller script, so existing tests are missing the synchronous subscriber path rather than disproving it.