`next build --webpack` (v16): `/_not-found` executed at build time + Google Font `Retrying 1/3...` visible — both absent in `next build` (Turbopack) — not seen in v14.2 webpack

[chandra2607]

Link to the code that reproduces this issue

https://github.com/chandra2607/nextjs-webpack-turbopack-issue.git

To Reproduce

git clone https://github.com/chandra2607/nextjs-webpack-turbopack-issue.git
cd nextjs-webpack-turbopack-issue

# Turbopack (next build)
docker build --build-arg BUILD_CMD=build -t repro-turbo . 2>&1 | tee out-turbo.txt

# Webpack (next build --webpack)
docker build --build-arg BUILD_CMD=build:webpack -t repro-webpack . 2>&1 | tee out-webpack.txt

# Compare
grep "not-found\|Retrying\|Generating static\|ƒ" out-webpack.txt
grep "not-found\|Retrying\|Generating static\|ƒ" out-turbo.txt

Current vs. Expected behavior

Current behavior:

• next build --webpack: webpack's static generation worker executes not-found.tsx at build time (side effects fire, fetches run) and logs Retrying 1/3... for transient Google Font download failures
• next build (Turbopack): static generation worker never enters not-found.tsx and emits no retry logs — the component is silently skipped
• Both produce the same final output: ƒ /_not-found (Dynamic)

Expected behavior:

Both bundlers should behave identically for /_not-found during the build. If the route is dynamic, neither should probe-render it. If one does, both should — so build-time side effects are predictable regardless of which bundler is used.

Provide environment information

Next.js:  16.2.1
Node:     22-alpine3.20 (Docker)
React:    19.0.0
OS:       Linux x86_64

Which area(s) are affected? (Select all that apply)

Webpack, Turbopack, Font (next/font)

Which stage(s) are affected? (Select all that apply)

next build (local)

Additional context

Hi everyone — I've been digging into some weird build log differences between next build --webpack and next build (Turbopack) and wanted to write up what I found in case others have run into the same thing or can add context.

There are two separate observations below. I'm not 100% sure whether either of these is a bug, a regression, or intentional — just sharing the data.

---

Observation 1 — not-found.tsx component body appears to run at build time with webpack, but not with Turbopack

What I noticed

When I run next build --webpack, I can see the body of my not-found.tsx getting executed during "Generating static pages" — even though /_not-found ends up classified as ƒ (Dynamic) in the build output. When I switch to next build (Turbopack), nothing in not-found.tsx runs at build time at all. Both builds show the same final route table.

Both produce:

Route (app)
┌ ƒ /
└ ƒ /_not-found

ƒ  (Dynamic)  server-rendered on demand

Repro component (not-found.tsx)

To keep things simple I stripped it down to a fully synchronous, no-async, no-fetch component:

export default function NotFound() {
  console.log("[not-found] component evaluated");
  console.log("[not-found] rendering");
  return (
    <main><h2>404 - Page Not Found</h2></main>
  );
}

Webpack build output

Generating static pages using 1 worker (0/1) ...
[not-found] component evaluated
[not-found] rendering
✓ Generating static pages using 1 worker (1/1) in 320ms

The component body runs during build.

Turbopack build output

Generating static pages using 1 worker (0/1) ...
✓ Generating static pages using 1 worker (1/1) in 230ms

No logs at all — the component wasn't touched.

What happens when not-found.tsx has a network call

With a fetch("http://missing-service:4005/test", { cache: "no-store" }) inside:

[not-found] component evaluated
[not-found] fetching remote data
[fetchRemoteData] about to fetch http://missing-service:4005/test
[fetchRemoteData] fetch failed (expected): Dynamic server usage: Route /_global-error ...

Turbopack: nothing. No logs, no fetch attempt.

Why this matters

If your not-found.tsx (or any component it imports) has side effects — reading env vars during module init, opening a DB connection, making a health-check request — those things appear to silently fire at build time under webpack but not under Turbopack. Code that's only been tested with next build could behave differently in environments that use next build --webpack.

I also tried export const dynamic = "force-dynamic" — it didn't change the behavior for either bundler.

Has anyone else seen this, or can confirm whether this is expected behavior?

---

Observation 2 — Retrying 1/3... shows up in webpack builds but not Turbopack when using next/font/google

What I noticed

When next/font/google is in layout.tsx, I mostly see this during the webpack compilation phase:

Creating an optimized production build ...

Retrying 1/3...

✓ Compiled successfully in 10.9s

This log never shows up in Turbopack builds.

Full example from a Docker build (node:22-alpine3.20)

Webpack:

▲ Next.js 16.2.1 (webpack)

  Creating an optimized production build ...

Retrying 1/3...
✓ Compiled successfully in 10.9s

Turbopack:

▲ Next.js 16.2.1 (Turbopack)

  Creating an optimized production build ...
✓ Compiled successfully in 5.7s

due to this issue , the overall build time takes longer to complete.

Has anyone else seen Retrying 1/3... in their webpack builds, especially in Docker or CI environments?

---

Comparison with Next.js 14.2

Neither of these behaviors appeared in next build --webpack on Next.js 14.2. The [not-found] component evaluated logs were absent and Retrying 1/3... was not reliably reproducible under the same Docker setup (node:22-alpine3.20). Both started showing up after upgrading to 16.x. Not sure if this is a regression or an intentional change in how the static generation worker handles /_not-found and how the font fetcher is implemented — mentioning it in case it helps narrow things down.

---

Environment

• Next.js: 16.2.1
• Node: 22 (Alpine 3.20 in Docker, native for local)
• React: 19.x
• OS: Linux (Docker) / macOS (local)

Related issues

• #76473 — Next.js build in GitHub Actions fails due to failed Google Fonts fetching
• #91653 — Turbopack Google Fonts http2 feature is not enabled on some platforms (16.2)
• #86390 — Turbopack crashes when Route Handler calls notFound()
• #62228 — not-found.tsx SSR differences