404: the account pages and the auth guard still return an empty-bodied 404 #139
Etiketter
Inga etiketter
area/backups
area/ci
area/control-panel
area/identity
area/infra
area/observability
area/payments
area/security
area/storage
area/web
blocked
needs-info
needs-triage
ready-for-implementation
type
bug
type
chore
type
docs
type
epic
type
feature
type
task
wontfix
Ingen milstolpe
Inget projekt
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Inget förfallodatum satt.
Beroenden
Inga beroenden satta
Referens
bitborg/bitborg-web#139
Läser in…
Hänvisa till i nytt ärende
Ingen beskrivning angiven.
Ta bort grenen "%!s()"
Borttagning av en gren är permanent. Även om den borttagna grenen kan fortsätta existera en kort tid innan den faktiskt tas bort, kan det INTE ångras i de flesta fall. Vill du fortsätta?
Follow-up to #134, which fixed the same bug shape in the
[slug]routes but scoped to those.new Response(null, { status: 404 })sends a null body, so the browser gets a 404 with nothing torender — worse than the framework default the issue set out to replace. #134 rewrote the four guide and
news slug routes to the branded page. Three places still return an empty-bodied 404:
src/pages/account.astro:18src/pages/en/account.astro:18src/lib/auth/guard.ts:25and:42account.astrois the straightforward half — the sameAstro.rewrite(getRelativeLocaleUrl(lang, "/404"))the slug routes now use.
guard.tsis the awkward one and is why this was not just folded into #134: it returns bareResponseobjects from a library function, so it has no
Astrocontext and no language. Fixing it properly meanseither threading the context in or having the guard signal "not found" and letting the page decide how
to render it — a small interface decision rather than a mechanical edit.
Done when
No route in the repository returns a 404 with an empty body, and a reader who hits one on the account
pages sees the branded page in their own language.