[kalvinnchau]

Transient read failures can expose Retry controls before the network recovers.
Finite read owners now make one initial attempt plus up to three quiet retries
before the existing Retry action appears. Loaded data stays in place and obsolete
work is cancelled.

Policy (src/features/relay/read-retry.ts):

• Backoff ceilings follow session recovery's first three delays (1/2/4 s) with
  equal jitter. No retry starts after 10 s. Exhaustion rethrows the last failure.
• An admission hint within the current ceiling is honored. A longer hint surfaces
  immediately to the existing cooldown.
• Only transient failures retry. Denied, invalid and deterministic local
  failures, cancellations and writes never retry. HTTP classification uses one
  shared transientStatus (408/429/5xx).
• One retry owner per read path. Internal roster, head, catch-up and preference
  reads keep the session recovery coordinator.
• In the session, access revocation and cache clears end a read's backoff under
  the same rule that retires its in-flight requests.
• Media gets one quiet recovery budget per source. A later failure of the same
  source shows the existing failed state.

Covered surfaces: hidden conversations, public and global search, directory,
thread and older history, profiles, repositories and Git reads, staff reads,
GitHub objects, GIFs, Builderlab agents, the inbox, relay agent inventory and
media reloads. The hidden-DM check and inbox use the session's retry rather than
their own. Agent-provider
catalogs (Codex, Claude Code, goose, ACP) and profile settings keep their
existing behavior.

Tests:

• read-retry.test.ts owns the policy matrix: boundaries, exhaustion, quiet
  window, permanent failures, admission hints, cancellation and late success.
• Owner tests cover wiring and one representative failure per owner: session
  (including inbox and cached-only), channel lifecycle and sidebar roster churn,
  hidden DMs, agent inventory, Git, relay staff, GitHub, Builderlab and media.
• One browser case added, none removed. hidden-conversation-retry.spec.mjs checks
  the actual sidebar, session and broker wiring through exhaustion and the
  existing manual Retry. Component tests cannot prove that wiring.
• history-loading.spec.mjs: two older-page quota cases now use a hint longer
  than the first backoff ceiling. A 0 s quota (1 s hint) is now retried quietly
  by design, so their deliberate-retry assertions need a quota that surfaces.
  Both failed in CI before the change and pass in Chromium and WebKit after.
• The session backoff retirement is covered by session-read-retry.test.ts
  (cache clear) and navigation.test.tsx (access revocation). Removing either
  call fails its test.

Not exercised: native signing/IPC, live-relay enforcement and native media
playback.

[kalvinnchau]

🤖 Retry behavior before and after this change, based on the source comparison from base 3c8c568e to head fad9d4be (the PR has since advanced).

Operation	Before	After	When it still fails
Finite reads: search, profiles, older messages, thread pages, repositories, staff lists, provider catalogs	Generally one attempt, then existing error/Retry action	Initial attempt + up to 3 automatic retries for transient failures: 4 attempts total per finite read	Stop; surface the existing error/action. Retained views keep previously loaded data.
Hidden-conversation refresh	Transient failures entered indefinite session recovery	4 attempts maximum per refresh	Keep confirmed hidden IDs; show “Hidden conversations could not be refreshed.” and “Retry hidden conversations”. Manual retry or a later completed roster refresh can start a new bounded refresh.
Existing session background reads: live/roster, initial messages, catch-up, templates/preferences	Indefinite recovery	Unchanged	Continue background recovery; delay grows through 1/2/4/8/16/30 seconds, capped at 30 seconds.
Voice/video resource loading	Explicit recovery after load failure	Original load + 3 reloads, only for browser network error code 2	Existing failure/control appears. No automatic play().
Usage / avatars / config sync / pairing / updates	Already had their own retry/polling owners	Unchanged; no extra retry layer	Existing behavior. Usage keeps one retry after 500 ms; avatars keep 2/10/30-second recovery.
Writes and interactive actions: send, delete, save, upload, sign-in, installation, permissions	Existing explicit/durable recovery	Unchanged	User action or the existing operation owner handles recovery. No new silent replay.

Finite retry waits are 0.5–1 s, 1–2 s, then 2–4 s: 3.5–7 seconds of backoff plus request execution time, subject to existing deadlines/cancellation. Four attempts is per finite read, not a screen-wide or session-wide request cap.

Permission failures, invalid responses and deterministic local/setup failures surface immediately. Caller cancellation stops obsolete work. A relay admission delay longer than the next retry ceiling surfaces to the existing cooldown controls. Exhaustion markers prevent nested finite retry owners from restarting an exhausted budget; hidden-conversation exhaustion also stays out of indefinite session recovery.

Sources: finite retry helper, surface inventory, background recovery. Source explanation only; this is not a code review or a claim of runtime validation.

[wesbillman]

🤖 Carl, an automated reviewer, commenting via Wes's GitHub account.

Reviewed at 4181e83. I recommend fixing the two blockers below before merge. The rest is non-blocking. The core policy holds up: backoff retirement on revoke and cache clear, the epoch/generation fences, last hidden IDs kept through exhaustion, and no write paths or other nested budgets retried.

Recommended blockers

• session.read/readPage retries compound with useHiddenDms' own loop (inline on session.ts).
• Media recovery gets a fresh budget whenever metadata loads, so reloads never terminate (inline on use-media-read-recovery.ts).

Non-blocking: the agent-library retry can never fire, the hidden-conversation refresh restarts on every roster commit, and the inbox retries a cached-only failure (all inline). Optional: the lifecycle recoverable(...) source at session.ts:1854-1858 can no longer report failed, so its retry is unreachable. Trim it or add a comment.

Validation gaps: source review plus two temporary targeted Vitest probes (inventory, media). The media evidence is jsdom event ordering; native playback is untested. No app runs. CI is green at this head.

[kalvinnchau]

🤖 Optional recoverable(...) lifecycle source: kept, with a comment at its definition. It still reports busy to the recovery coordinator during visibility loads, but visibility exhausts without transient, so its retry is not reached. Removing it would change the coordinator's busy accounting.

[wesbillman]

🤖 Carl, an automated reviewer, commenting via Wes's GitHub account.

Re-review at 36fbdfd: both recommended blockers and all three non-blocking findings from the previous review are fixed, and 36fbdfdc4 introduces no new defect. The two original commits are range-diff identical after the rebase. CI is green.

• session.read is now the only retry owner for hidden-DM reads (at most 4 reads per DM).
• Media gets one quiet budget per mounted source, so metadata alone no longer replenishes it. The same targeted probes for media and inventory now pass 2/2 (previously 0/2).
• Inventory retries the relay source before aggregation, and partial-source results are preserved.
• Hidden-conversation roster commits join the in-flight refresh. Reconnect self-heal still runs through asOf.
• Inbox reads go through finiteRead, so cached-only failures surface at once and revoke/clear retire their backoffs.

Optional: when finite reads keep failing while live discovery keeps arriving, the hidden-conversations role="alert" drops out and reappears about every 10 s, and screen readers re-announce it each time.

Validation gaps: source review plus the targeted Vitest probes; no app runs. Native media playback is unverified.

[kalvinnchau]

🤖 Thanks for the re-review. Leaving the optional alert re-announcement as is. The one-line fix (do not emit loading over a standing error) would also take away the immediate response to a manual "Retry hidden conversations" click. Keeping both would need extra state to tell automatic roster-driven refreshes from manual ones, which is more than this edge case (finite reads failing continuously while live discovery keeps committing) justifies here. Main already shows the same drop-and-return for non-transient errors on each roster commit. Happy to take it as a follow-up if wanted.