Skip to content

fonts: false breaks the entire admin UI — admin.astro renders <Font> unconditionally, causing a silent empty response #2527

Description

@timmillwood

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

  1. emdash({ ..., fonts: false }) in astro.config.mjs.
  2. Build and deploy (or astro dev).
  3. Visit /_emdash/admin (or any /_emdash/admin/* route).
  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions