[loganj]

🤖

Summary

• Problem: when a laptop wakes before its network (or VPN) is back, Buzz shows a stack of separate error boxes ("Retry templates", "Retry Me", "Retry live updates", "Saved sidebar preferences couldn't refresh"), channels can vanish from the sidebar, and live updates give up after about 15 seconds. When the network returns, nothing recovers by itself. You click every Retry button or restart the app.
• Now: Buzz keeps retrying failed background reads by itself, with backoff (1s, 2s, 4s… up to every 30s) and no attempt limit. It also retries at once on wake, when the network comes back, when the window gets focus, and when the live connection reconnects. A failure that one retry fixes shows nothing. A longer one shows one "Reconnecting to relay…" notice with one "Retry now" button. When the relay answers, the notice goes away and every panel refills with no click.
• Retry buttons for your own actions (a failed move, delete or upload) are unchanged. Those resend something you did, so the app must not repeat them silently.

Screenshots

Both runs use the same browser test scenario: open the app, drop the relay connection and answer every relay request with a non-relay 403 page (like a VPN still reconnecting), then restore the network.

Before — network down (channel Alpha has gone from the sidebar, "Relay read cancelled", a manual "Retry live updates"):

Before — 30 seconds after the network returns (unchanged; it stays broken until you click or restart):

After — network down (loaded messages and channels stay; one notice, one Retry now):

After — network returns, no click (notice gone, channels and messages load again):

Details

• One recovery owner per relay session (src/features/relay/recovery.ts). Each background read (live stream and channel list, channel templates, Me placement, sidebar preferences, hidden conversations) reports failed / busy / settled. While any source fails, the owner retries every failed source on one shared backoff. A retry still in flight keeps the notice up, so the delay does not reset into a 1-second loop.
• Live streams: fix(client): recover websocket connections across repeated rollouts #996 already stopped the WebSocket stream from giving up after 5 attempts; this PR keeps main's version of that code. This PR does the same for the broker stream: it backs off to a 30-second cap and keeps going.
• Connection errors now retry on the same backoff instead of waiting for a click.
• Wake detection: a 5-second timer that sees a gap over 15 seconds treats it as a wake, because a desktop window does not always report focus after sleep.
• Edge 401/403 pages: a 401/403 whose body is not the relay's own JSON refusal (for example a proxy page while a VPN reconnects) is now treated as "unavailable" and retried. Real relay refusals still read as denied. The browser broker returns 502 for such pages.
• Only transient failures retry automatically: network loss, timeouts, cancellation, relay or host unavailable (5xx), and live closes except the needs-action NIP-01 prefixes (restricted:, blocked:, invalid:, auth-required:, unsupported:, pow:, duplicate:). A denial, a terminal sign-in failure or a deterministic check (for example the recipe catalog read limit) keeps its own message and its own Retry button, and the connection does not reconnect on it. Retrying those forever would hide the reason and change nothing (errors.ts isTransientFailure, live-recovery.ts).
• Suspended public previews: when a public preview gets CLOSED restricted: and its metadata recheck fails, the recheck is now a failed recovery source, so the timer and wake signals retry it. Access stays suspended until fresh signed metadata succeeds.
• UI: the per-panel Retry buttons for outage failures are removed. Inside a conversation the notice sits above the composer; elsewhere it is a single floating notice. The notice has its own visibility latch, so Retry now and wake signals restart the backoff without hiding the notice mid-retry. If recovery removes a focused Retry now button, focus moves to the composer, or to the history in a public preview, which has no composer. While the notice shows, an empty timeline that failed in the outage shows "Loading messages…" instead of its own Retry messages. A terminal live failure (rejected sign-in or failed signing) keeps a "Retry live updates" button, because automatic recovery does not retry it. Notices that automatic retry cannot fix (a partial channel roster, capacity limits) stay, without a Retry button.
• The before screenshots come from the same test run on main at bc6e9ed (earlier today, before this branch).

[kalvinnchau]

🤖 Code-only review: three actionable recovery regressions below. Recommend fixing these before merge. Runtime validation was unperformed.

[kalvinnchau]

🤖 Follow-up code-only review: preview recovery and notice visibility fixes are addressed. One new terminal-live recovery gap remains below. Runtime validation unperformed.

[kalvinnchau]

🤖 approved. the missing conversation retry after an auth/signing failure can be handled as a non-blocking follow-up; ActivityPanel retry or restarting provides a workaround. code-only review; runtime validation unperformed.