fix(web): keep signed-in shell visible through auth outages - #807
Conversation
When the session gate's revalidation returns "auth unavailable" but an identity is already known (sessionStorage cache or the SSR seed), keep the painted shell up and retry get-session in the background (10s/30s/60s) instead of blanking the whole app into the blocking "try again" screen. Auth outage is not a sign-out: every API call still enforces the real session server-side, so page data degrades to its own error states while the chrome stays usable. A visit with no known identity still gets the blocking screen, and a background retry that finds the session signed out redirects to /login as before. Surfaced by the 2026-08-23 D1 stall incident, where 4s-bounded get-session 503s were flipping fully-rendered pages into the hard failure state.
|
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
uploads-web | 484dd28 | Commit Preview URL Branch Preview URL |
Aug 23 2026, 11:03 PM |
|
Important Review skippedAuto reviews are limited based on label configuration. 🏷️ Required labels (at least one) (2)
🚫 Excluded labels (none allowed) (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
What
During an auth outage (like today's D1 stalls), the session gate's background revalidation returns "unavailable" — and until now that blanked the entire already-rendered app into the blocking "Authentication is temporarily unavailable" screen, even though the user's identity was already known from the sessionStorage cache or the SSR seed.
Now
resolveSessionGatetreats an outage with a known identity as a soft failure:This is safe because the cache was always a UX affordance only: every API call re-enforces the real session server-side, so page data degrades to its own per-request error states while the chrome stays usable.
Why now
Follow-up to #805/#806. With get-session bounded at 4s, a D1 stall window turns into fast 503s — correct fail-fast behavior, but the gate was amplifying one failed revalidation into a full-app hard failure on pages that were already rendered and usable.
Testing
resolveSessionGatetests: shell stays up on unavailable-with-cache, stays up through exhausted retries, still blocks with no identity, redirects when a retry finds signed-out.