fix: stop an error response from crashing the page (#53)

[pataniaeli]

Fixes #53.

What happened

fetch('/api/spaces')
  .then(r => r.json())
  .then((data: Space[]) => setSpaces(data))

That annotation is a promise the code can't keep. An error response is still valid JSON, so on a 401 r.json() resolves happily with { error: 'Unauthorized' }, that object lands in state typed Space[], and the page dies on the next spaces.find(...) — the reported l.find is not a function.

The intermediate data.length > 0 had already passed silently, because undefined > 0 is just false. So nothing failed until the render, well away from the actual cause.

TypeScript can't catch this. The cast is asserted at a boundary where the real shape is only knowable at runtime.

It wasn't only that page

Eight call sites shared the pattern. Four degrade harmlessly on their own (data.groups || [], (requests ?? [])), but the rest didn't:

site	what happened on a non-200
sga-spaces/page.tsx	the reported crash
sga-spaces-tab.tsx	.then(setSpaces) — identical shape, admin view
booking-settings-tab.tsx	worse than a crash — see below
settings-modal.tsx	error body cast to Settings, offered back for saving
archive-tab.tsx	no .catch at all, so setLoading(false) was unreachable and the tab hung on its skeleton forever

booking-settings-tab is the one that worried me most. Every field falls back to a hardcoded default (?? 0, ?? 24), so an error body silently populated the form with 0 / 0 / 24 — and an admin who then pressed Save would have written those over the real booking limits. A crash is loud; that is silent data loss.

The fix

getJson / getJsonArray take the fallback as an argument, so the failure case can't be left out and the return type stays honest.

The Spaces page handles its response directly instead, because there an empty list is a meaningful answer — "no rooms configured" — and quietly substituting one for a failed request would state something untrue. It now shows a short error with a Try again button, which is the same remedy the reporter found by reloading.

Verified

Ran the real helper against the exact failure (Node 24 strips types, so this exercises lib/fetch-json.ts itself, not a copy):

PASS  401 -> array fallback, not the error object
PASS  401 -> object fallback
PASS  200 list passes through
PASS  200 non-array -> []
PASS  500 -> fallback
PASS  network reject -> fallback
PASS  non-JSON body -> fallback
PASS  spaces.find() is callable after a 401   ← the crash itself

Build passes, typecheck clean, and lint comes out 3 warnings better than dev (14 errors / 99 warnings vs 14 / 102) — the removed empty .catch(() => {}) blocks.

Not fixed here

Why /api/spaces returns a 401 in the first place. I checked whether it was a regression from the recent auth work and it isn't: both endpoints in the report use the plain getAuthedUser path that wasn't touched, no user is missing a profile row, no sessions are revoked, and no users are inactive. Workbox's NetworkFirst only caches 200s, so the service worker isn't replaying it either.

That leaves a transient auth failure — most likely an expired access token racing the cookie refresh, which fits "a reload fixed it". Worth chasing separately; what this PR guarantees is that it can no longer take a page down. I'd suggest keeping #53 open, or opening a follow-up, to track the 401 itself.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
chambers	Ready	Preview	Aug 28, 2026 9:40pm

[pataniaeli]

Added: sign out this device only (ec9ccc6)

signOut() defaults to scope 'global' — confirmed in auth-js:

async _signOut({ scope } = { scope: 'global' })

That revokes every refresh token the user holds anywhere. So the 44-minute idle timer firing on someone's laptop also ended the session on their phone, in their other tab, and the copy the Edge middleware refreshes. Each of those then failed its next refresh with a 400 and began serving 401s — which is how a page that worked a moment ago starts returning Unauthorized.

Supabase logs over 24h support it: of 28 refresh_token grants, 9 returned 400 (5 browser, 4 Edge middleware), alongside 28 logouts across ~27 users. And only 3 of 24 refresh tokens have ever had a parent, so rotation is barely occurring — meaning a 400 is a revoked token rather than a rotation race.

The split

scope	where	why
local	dashboard-shell: Sign Out button + 3 idle paths	this browser, not every device you own
global	deactivation (force-sign-out, LoginCard, onboarding) + expired invite	the account may not be used at all — ending every session is the point

The global ones now carry a comment saying why, so they don't get "unified" later for consistency.

This is worth having regardless of the 401s: signing out at a library machine shouldn't log you out on your phone.

What I'm not claiming

That this accounts for every 401. Vercel's runtime logs return 403 for my token, so I couldn't tie the reported failure to a specific revocation, and some 400s fall in hours with no logouts at all. Treat it as the leading cause with good evidence behind it, not a closed case — worth re-checking the refresh 400 rate after this ships.

Build and typecheck pass; lint is 3 warnings better than dev.