next/font/google: a 404 on a font file is reported as "Module not found" and never retried

[lucasmcht]

Link to the code that reproduces this issue

https://github.com/lucasmcht-corp/next-font-404-repro

To Reproduce

git clone https://github.com/lucasmcht-corp/next-font-404-repro
cd next-font-404-repro
npm install
npm run build:mocked

The build exits 1 with:

Received response with status 404 when requesting https://fonts.gstatic.com/s/bitter/v42/this-file-does-not-exist.woff2
> Build error occurred
Error: Module not found: Can't resolve '@vercel/turbopack-next/internal/font/google/font'

The stylesheet is served through Next's own NEXT_FONT_GOOGLE_MOCKED_RESPONSES hook, so no CDN behaviour is involved. It points at a font file URL that does not exist, so the file fetch, which is not mocked, answers 404 on every machine, every time.

Current vs. Expected behavior

Current: a single failed font file download stops the build with Module not found: Can't resolve '@vercel/turbopack-next/internal/font/google/font'. The HTTP status appears only as a warning earlier in the log, easily lost in a large build. There is no retry.

Expected: the fetch is retried, and if it still fails the build error names the network failure, the URL and the status code, instead of an internal module.

Where it happens

In crates/next-core/src/next_font/google/mod.rs:

• fetch_from_google_fonts, L662-681 makes one request, emits an issue at IssueSeverity::Warning, returns None.
• NextFontGoogleFontFileReplacer, L419-425 turns that None into ResolveResult::unresolvable().

Why this matters outside the mock

The same path is reached with no mock at all. On 16.3.1 our production builds failed at random, on a different family each run (Bitter, Montserrat, Noto Serif), with .next deleted before each build, because the stylesheet returned by fonts.googleapis.com pointed at files fonts.gstatic.com had already rotated away. Checked again while writing this:

URL	status
.../notoserif/v33/ga63aw1J5X9T9RW6...QLqNQw.woff2 (requested by the build)	404
.../notoserif/v33/ga6daw1J5X9T9RW6...WsNFHuQk.woff2 (returned today for the same family)	200

A likely trigger, offered as a hypothesis since I could not capture the stylesheet the failing build received: fonts.googleapis.com/css2 answers with cache-control: private, max-age=86400, stale-while-revalidate=604800 and vary: Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site. The fetcher sends no Sec-Fetch-* headers, so it addresses its own cache entry, one browsers never keep warm, which may be served stale for up to seven days while the files it names are rotated.

That hypothesis is only about what makes the fetch fail. The reproduction above is about what Next does when it does fail, which is deterministic and independent of it.

Suggested fix, in order of value

1. Retry the font file fetch before giving up.
2. Report the HTTP status and URL as the build error instead of a missing module.
3. Optionally send Sec-Fetch-Dest: style on the stylesheet request, so the fetcher shares the cache entry browsers keep warm.

Related

• next/font/google: a 404 on a font file is reported as "Module not found" and never retried #97376, same report without a reproduction, closed automatically.
• next/font/google: intermittent "Module not found: Can't resolve '@vercel/turbopack-next/internal/font/google/font'" for CJK fonts in dev (always) and build (intermittent) — regression in 16.3.0 #97344, same intermittent build failure, also closed for a missing reproduction link.

Environment

next 16.3.1
node 22.23.0
Linux x64
App Router, next/font/google

[SparshGarg999]

Proposed Plan to Improve next/font/google 404 & Network Fetch Error Handling

When fetching Google Font files fails with HTTP 404 or network errors during font module resolution in @next/font, the fetch failure is currently caught and re-thrown as generic module resolution failure ("Module not found"). This prevents actionable diagnostics and stops automatic build/dev retries.

Fix:
Preserve and surface the underlying HTTP response status code and network error context in @next/font/google fetch error handlers rather than masking them under generic ModuleNotFoundError.

[captain-jack-sparrow909]

I used this deterministic reproduction as a field case for BugBonsai, a local-only minimal-reproduction reducer.

Using the published 0.1.0-beta.4 against commit c7355acb832acb8831c9773a663b5e63cf3ba94f:

npx bugbonsai@0.1.0-beta.4 \
  --match turbopack-next/internal/font/google/font \
  --no-install -- npm run build:mocked

It preserved the reported Turbopack failure twice before pruning and three times during final validation, ending with four project files. The run stayed local and uploaded no source or logs.

For clarity, this run used --no-install, so I am treating it as engine/reduction evidence rather than claiming the output is a self-contained recipient bundle. The reproduction was useful enough to expose and fix a Next/Turbopack dependency-isolation bug in BugBonsai itself (PR #20). Thanks for providing a deterministic case.

[luantaraschi]

Two things I checked in the tree while reading this, in case they help decide the shape.

The webpack path already retries. next-font-loader, registered at packages/next/src/build/webpack-config.ts:1404, goes through packages/font/src/google, where fetch-css-from-google-fonts.ts:26 and fetch-font-file.ts:17 both wrap the request in retry(). The Turbopack path does not: fetch_from_google_fonts at crates/next-core/src/next_font/google/mod.rs:662 makes one request and returns None, and mod.rs:424 turns that into ResolveResult::unresolvable(), which is where the Module not found comes from. So this looks less like a new feature and more like the two bundlers answering the same failure differently, with Turbopack being the default.

The existing mock only covers the stylesheet. NEXT_FONT_GOOGLE_MOCKED_RESPONSES is read at mod.rs:236 and swaps only the stylesheet fetch. The font file fetch at mod.rs:420 always goes to the network, which is why the reproduction here has to point at a URL that really 404s on fonts.gstatic.com. Unless I am missing something, that leaves no offline way to cover this path in test/e2e/next-font/google-fetch-error.test.ts, which is where the sibling stylesheet failure is already pinned.

That second point is the part I am unsure about, so before writing anything: would you want the mock hook extended to cover font files so this can be tested offline, or is there a direction you would rather take here? Happy to send the retry once the shape is settled.