Critical: Relay 'Reconnect to Relays' button disconnects but never reconnects; persists across app restart and cache clear

[variablefate]

Severity

Critical — effectively bricks both apps (rider + drivestr). No Nostr → no rides, no offers, no chat, no profile/wallet sync. User cannot recover via normal means (force-close, cache clear all fail).

Steps to Reproduce

1. Open the app, navigate to Settings → Relay Management.
2. Tap "Reconnect to Relays".
3. Observe: all relays drop to disconnected and never come back.
4. Tap the button again → no effect (does not force reconnect).
5. Force-close the app and relaunch → still no relay connections.
6. Clear app cache → still no relay connections.

Expected Behavior

• Tapping "Reconnect to Relays" should briefly drop and re-establish WebSocket connections to all configured relays.
• At minimum, a subsequent tap, or a fresh app launch, should restore connectivity.

Actual Behavior

• All relays go to DISCONNECTED and stay there.
• The button becomes a no-op on repeat presses.
• App restart and cache clear do not recover the connection state.

Affected Code (both apps share common/)

Handler wiring (identical in both MainActivities):

• rider-app/src/main/java/com/ridestr/rider/MainActivity.kt:804
• drivestr/src/main/java/com/drivestr/app/MainActivity.kt:1006
• roadflare-rider/src/main/java/com/roadflare/rider/MainActivity.kt:379 (uses ensureConnected() — possibly not affected, worth confirming)

onReconnect = {
    nostrService.relayManager.disconnectAll()
    nostrService.relayManager.connectAll()
}

UI button: common/src/main/java/com/ridestr/common/ui/RelayManagementScreen.kt:122 — the isReconnecting flag flips back to false after a fixed delay regardless of actual connection result, which masks failure and produces the "button does nothing" feel on retry.

Manager / connection:

• common/src/main/java/com/ridestr/common/nostr/relay/RelayManager.kt:116 (connectAll / disconnectAll)
• common/src/main/java/com/ridestr/common/nostr/relay/RelayConnection.kt:78 (connect)
• common/src/main/java/com/ridestr/common/nostr/relay/RelayConnection.kt:102 (disconnect)
• common/src/main/java/com/ridestr/common/nostr/relay/RelayConnection.kt:235 (scheduleReconnect)

Suspected Root Cause(s)

A disconnectAll() immediately followed by connectAll() runs on the UI thread. RelayConnection.disconnect() sets shouldReconnect = false and closes the socket asynchronously outside the lock. connect() then sets shouldReconnect = true and opens a new socket. Several things can go wrong:

1. Stale-callback path: the new socket's onOpen may fire before the old socket's onClosed arrives. The onClosed guard checks socket !== webSocket and bails — but if any callback orders differently against state assignment, we can land in a state where _state.value == DISCONNECTED while socket references a now-dead WebSocket.

2. connect() short-circuit: connect() returns early if state is CONNECTING or CONNECTED. If a previous reconnect attempt left state stuck in CONNECTING (e.g. a never-completed handshake on a torn-down socket), subsequent presses become no-ops. This matches the "second press does nothing" symptom.

3. Survives restart / cache clear: This is the strongest clue that something persisted matters. Cache clear preserves SharedPreferences (only cache dir is wiped). If the user has custom relays saved and one or more of them is unreachable, the relay list itself may be the actual problem — but the UI gives zero feedback. Worth verifying whether the user has custom relays configured. Also worth checking that RelayManager is initialized from the current effective relay list rather than RelayConfig.DEFAULT_RELAYS (see RelayManager.kt:43) — if NostrService is constructed once with defaults, custom relays set later may never be honored.

4. No retry budget reset on manual reconnect: reconnectAttempts backoff persists across the manual button press. If we've already backed off to 60s, the user may think nothing's happening when in fact a delayed retry is pending.

Suggested Fix Direction (for triage, not prescriptive)

• Make onReconnect call a dedicated relayManager.forceReconnectAll() that:
  • Resets reconnectAttempts to 0 on each connection,
  • Awaits actual socket teardown before re-opening (don't fire-and-forget),
  • Re-reads the effective relay list from SettingsRepository so custom relay changes take effect,
  • Returns a result the UI can surface (success / per-relay failure with reason).
• Surface per-relay errors in the UI rather than only showing aggregate connected count.
• Add an "are you using custom relays?" diagnostic line on the Relay Management screen.

Environment

• Reported via internal test on 2026-05-14.
• Branch: claude/cranky-curie-1d8700 (master at fa54d0a).
• App(s): rider-app and drivestr (shared common/ code — both should be affected; please confirm).

Acceptance Criteria

• Tapping "Reconnect to Relays" reliably drops and re-establishes connections.
• On failure, the UI shows which relay(s) failed and why.
• App relaunch always re-establishes connections (no persistent stuck state).
• Custom relay edits take effect on next reconnect without app restart.
• Integration test covering rapid disconnect → connect cycle and the "second press" case.

[variablefate]

Clarification from reporter: they were on default relays at the time, not custom ones.

This rules out hypothesis #3 (custom relay list / stale RelayManager init from RelayConfig.DEFAULT_RELAYS). The relay set being attempted is correct.

That actually makes the bug more interesting, because:

• A force-close kills the process → fresh OkHttpClient, fresh RelayManager, fresh sockets.
• Cache clear wipes the cache dir but preserves SharedPreferences.
• On a fresh launch with default relays, connection should "just work" unless something persisted by the button press is poisoning the new process.

Sharpened suspect list:

1. In-memory WebSocket race (Driver app needs wallet setup screen in onboarding flow #1/Replace expanded area search button with hashtag-based ride discovery popup menu #2 from the issue body) — explains the initial failure and the "second press does nothing" symptom, but does NOT explain why a fresh process can't connect.
2. Something persisted on the failing reconnect path — worth auditing whether the reconnect handler (or any callback it triggers) writes to SharedPreferences. If the button press somehow flips isUsingCustomRelays=true with an empty list, fresh launches would have zero relays to connect to. Check SettingsRepository for any writes triggered by relay state changes.
3. Transient network condition that coincidentally lasted across the user's debugging session — possible but doesn't match the "tried multiple times" detail.

Priority on root-cause #2: it's the only explanation consistent with "survives force-close + cache clear" on default relays.