fix(desktop): deduplicate relay outage notification

[loganj]

🤖

Summary

• Keep the relay reconnect notification dismissed across repeated connection retries during one continuous outage.
• Re-arm the notification after recovery or relay lifecycle replacement, including switches between communities that use the same relay URL.
• Preserve the existing dedicated path for authentication and other application-level errors.

How an outage is tracked

The AppShell-owned relay-card hook treats an outage as one contiguous runtime episode rather than assigning it a persisted ID. A hook-local outageActiveRef is armed by the first qualifying unreachable/degraded observation. While it is armed, intermediate retry states (connecting, reconnecting, stalled, and disconnected) belong to that same episode, so retry churn cannot clear dismissal or emit another notification.

The hook receives the same lifecycle identity used by community initialization: community ID plus reinitKey. This distinguishes multiple communities even when they share a relay URL, and it also changes when the active community is explicitly reinitialized. The latch and dismissal are reset when that identity changes or when the relay singleton reports its authoritative idle teardown state. A successful connected state also closes the episode and re-arms the next outage.

These boundaries deliberately bias toward re-notifying rather than suppressing a later outage: recovery, community switch/reinit, or relay teardown cannot leave the hook stuck believing an old outage is still active. No outage state is persisted beyond the mounted hook lifecycle.

Related issue

None found.

Testing

• pnpm --dir desktop typecheck
• pnpm --dir desktop test — 3,769 passed
• pnpm --dir desktop check
• pnpm --dir desktop build:e2e
• pnpm --dir desktop exec playwright test tests/e2e/sidebar-relay-card.spec.ts --project=integration — 11 passed

[Chessing234]

Sensible outage-episode model. Keeping the reconnect toast dismissed for one contiguous unreachable stretch (and re-arming on recovery / community switch even when the URL is unchanged) matches how operators experience a flaky relay. Glad the dedicated auth/application-error path is preserved. The e2e coverage on the sidebar card helps. One watch-item: confirm outageActiveRef resets when the hook unmounts between community switches that remount AppShell children — the description says it does via lifecycle replacement; if that's only a URL-keyed effect, a same-URL remount edge case could leave it sticky.

[wpfleger96]

Reviewed exact remote head 2d5916517d0e6bd309bb53a3b58d16e22337c1f0.

Review

No blocking or non-blocking findings.

What's Solid

• The outage latch models the user-visible invariant directly: only the first degraded observation opens an episode, so connecting / reconnecting / stalled / disconnected retry churn cannot clear a dismissal.
• Recovery is authoritative: connected closes the episode and re-arms the next outage. idle teardown and the community ID + reinitKey lifecycle identity handle singleton replacement and same-URL community transitions without carrying stale dismissal state.
• The existing auth/application-error split is preserved: terminal disconnected with a non-unreachable error still stays on the dedicated error path.
• The state remains hook-local and ephemeral; no persistence or new cross-module store was added.
• The tests cover cold-start failure, dismissal through retry churn, recovery, a second outage, and lifecycle teardown. Existing success-card, stale-error suppression, collapsed-sidebar, stalled-state, and auth-error behaviors remain covered.
• All GitHub checks are green. I independently ran just desktop-test (3,769 passed, 0 failed) and pnpm build:e2e && pnpm exec playwright test tests/e2e/sidebar-relay-card.spec.ts --project=integration (11 passed, 0 failed) at exact head 2d5916517d0e6bd309bb53a3b58d16e22337c1f0; the SHA was unchanged before and after both runs.

Alternatives

None preferable. A reducer or module-level outage store would add machinery without improving the hook-local lifecycle contract.

Quality Gate

• Minimalism: 9/10 — one lifecycle input, two refs, and one consolidated effect; each addition enforces an explicit outage boundary.
• Elegance: 9/10 — the episode transitions read in the same order as the product behavior: lifecycle reset, teardown, outage start, recovery.
• Correctness: 9/10 — cold start, retry churn, recovery/re-arm, lifecycle replacement, stale errors, and auth failures are handled and behaviorally covered.

Verdict: Approve.