nextjs - 💡(How to fix) Fix 16.2.3: HTTPAccessFallbackBoundary swallows notFound() status code when dynamic route has sibling loading.tsx [1 comments, 2 participants]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
Binaries:
  Node: v24.13.1
Relevant Packages:
  next: 16.2.3
  react: (19.x)

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

Dynamic Routes, Linking and Navigating, Not Found

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

next dev (local), Vercel (Deployed)

Link to the code that reproduces this issue

Inline minimal repro (3 files, [email protected] scaffold):

app/[id]/page.tsx

import { notFound } from "next/navigation";

export default async function Page({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params;
  if (id !== "real") notFound();
  return <h1>ok</h1>;
}

app/[id]/not-found.tsx

export default function NotFound() {
  return <h1>not found</h1>;
}

app/[id]/loading.tsx

export default function Loading() {
  return null;
}

To Reproduce

pnpm create [email protected] repro --ts --app --no-tailwind --no-src --no-turbopack --import-alias "@/*"
cd repro && add the 3 files above
pnpm build && pnpm start
curl -sI http://localhost:3000/missing

Actual response:

HTTP/1.1 200 OK

Expected response:

HTTP/1.1 404 Not Found

Current vs. Expected behavior

Actual: the rendered body is the correct not-found.tsx content, but HTTP status is 200 OK.

Expected: HTTP status is 404 Not Found (regardless of streaming). SEO crawlers and state-matrix audits treat this as a live page.

Tracing the code path in [email protected]:

• app-render.js:1894 — continueFizzStream flushes response headers as soon as the shell renders.
• Server component calls notFound() → the nearest HTTPAccessFallbackBoundary (dropped in by the framework around not-found.tsx) catches it and renders the not-found.tsx tree inline.
• Because the boundary swallows the error, the framework-level handler at app-render.js:1949 that would set res.statusCode = 404 never runs.
• export const dynamic = 'force-dynamic' by itself does not flip generateStaticHTML off this branch; removing loading.tsx (which is what triggers Suspense wrapping) is the only workaround at the framework level.

Prior art

• #76474 — closed, same symptom on 14.2.0 (loading.tsx + dynamic route)
• #45801 — closed, same symptom on 13.1 (loading.tsx anywhere)
• #62228 — open, adjacent (404 page is not SSR'd)
• #82041 — open, adjacent (non-streaming generateMetadata)

Re-filing against 16.2.3 because the prior dynamic-route issue was closed without a behavioral fix and the symptom is still present on current stable.

Why this matters

This forces any app with streaming enabled (loading.tsx present anywhere in the segment tree) to implement a middleware/proxy-layer 404 shim that does its own existence check against the DB before the route renders. We ended up writing one here:

https://github.com/holden-cgk/cgk-dashboard/blob/main/src/proxy.ts

…which duplicates work the page.tsx already does on valid loads. A framework-native path (e.g., "if a component throws notFound() inside the boundary, persist that to the response status even on streamed responses") would let us retire the shim and avoid the duplicate round trip.

Workarounds

• Remove loading.tsx from the segment — disables streaming, restores 404 — but loses the loading UX.
• Intercept in middleware/proxy: validate the ID and do a SELECT 1 existence check before the render starts. Expensive (extra round trip) but returns a real 404.
• export const dynamic = 'force-dynamic' alone does not fix this.

Happy to contribute a PR if there's interest in landing a framework-level fix — would appreciate a pointer on whether this is considered tractable in the streaming codepath before investing the time.