Summary
Setting fonts: false in the emdash() integration config — documented as "disable font injection entirely and use system fonts" — completely breaks the admin UI instead of falling back to system fonts. Every route under /_emdash/admin/* (dashboard, login, the first-run setup wizard) returns HTTP 200 with a completely empty body, with no error surfaced anywhere visible to the user or in application logs.
Root cause
packages/core/src/astro/routes/admin.astro unconditionally renders:
<Font cssVariable="--font-emdash" />
When fonts: false is passed to emdash(), the integration sets emdashFonts = [] and injects that empty array as Astro's fonts config, so no font family is ever registered for --font-emdash. Astro's <Font> component throws AstroError(FontFamilyNotFound) when it can't find a matching registered family — and since this happens partway through streaming the SSR response, the error is thrown after the 200 status and headers have already been sent to the client. The stream just ends with zero bytes; there's no way to downgrade to a 500 at that point, and nothing logs the underlying error in a way that's easy to find.
Repro steps
emdash({ ..., fonts: false }) in astro.config.mjs.
- Build and deploy (or
astro dev).
- Visit
/_emdash/admin (or any /_emdash/admin/* route).
- Response is
200 text/html with a 0-byte body. No visible error.
Fix
Opened in #2526 — guards the <Font> render on Astro's actual font registry instead of assuming a family is always available.
Secondary note (optional, separate from the fix above)
Independent of this specific bug: an SSR component throwing mid-stream degrading silently to "200 + empty body" is a rough failure mode in general — worth considering whether the admin shell route (or Astro itself) could catch stream errors and at least log a clear diagnostic. This bug took real effort to trace precisely because nothing in the response or logs pointed at the cause.
Environment
- Astro 7.2.2,
@astrojs/cloudflare adapter (Hyperdrive/Postgres), but the bug is adapter-agnostic — it's in admin.astro itself.
Summary
Setting
fonts: falsein theemdash()integration config — documented as "disable font injection entirely and use system fonts" — completely breaks the admin UI instead of falling back to system fonts. Every route under/_emdash/admin/*(dashboard, login, the first-run setup wizard) returnsHTTP 200with a completely empty body, with no error surfaced anywhere visible to the user or in application logs.Root cause
packages/core/src/astro/routes/admin.astrounconditionally renders:When
fonts: falseis passed toemdash(), the integration setsemdashFonts = []and injects that empty array as Astro'sfontsconfig, so no font family is ever registered for--font-emdash. Astro's<Font>component throwsAstroError(FontFamilyNotFound)when it can't find a matching registered family — and since this happens partway through streaming the SSR response, the error is thrown after the 200 status and headers have already been sent to the client. The stream just ends with zero bytes; there's no way to downgrade to a 500 at that point, and nothing logs the underlying error in a way that's easy to find.Repro steps
emdash({ ..., fonts: false })inastro.config.mjs.astro dev)./_emdash/admin(or any/_emdash/admin/*route).200 text/htmlwith a 0-byte body. No visible error.Fix
Opened in #2526 — guards the
<Font>render on Astro's actual font registry instead of assuming a family is always available.Secondary note (optional, separate from the fix above)
Independent of this specific bug: an SSR component throwing mid-stream degrading silently to "200 + empty body" is a rough failure mode in general — worth considering whether the admin shell route (or Astro itself) could catch stream errors and at least log a clear diagnostic. This bug took real effort to trace precisely because nothing in the response or logs pointed at the cause.
Environment
@astrojs/cloudflareadapter (Hyperdrive/Postgres), but the bug is adapter-agnostic — it's inadmin.astroitself.