[GH-ISSUE #346] renderHTTPAccessFallbackPage does not pass params to layout components #79

New issue

Closed

opened 2026-05-06 12:37:03 +02:00 by BreizhHardware · 1 comment

BreizhHardware commented

2026-05-06 12:37:03 +02:00

Owner

Originally created by @Jbithell on GitHub (Mar 8, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/346

renderHTTPAccessFallbackPage does not pass params to layout components

When vinext renders HTTP access fallback pages (404, 403, 401), layout components are rendered without the params prop, causing layouts that destructure route params to crash with:

Cannot destructure property 'lang' of '(intermediate value)' as it is undefined.

Root cause

In the bundled output, renderHTTPAccessFallbackPage creates layout elements with only { children } and no params:

// renderHTTPAccessFallbackPage path — no params passed
const LayoutComponent = layouts[i3]?.default;
if (LayoutComponent) {
  element = createElement(LayoutComponent, { children: element });
}

The normal render path correctly passes params:

// normal render path — params passed correctly
const layoutProps = { children: element, params: makeThenableParams(params) };

This affects both the RSC and non-RSC branches within renderHTTPAccessFallbackPage.

Reproduction

Create a Next.js app with a dynamic [lang] route segment
In app/[lang]/layout.tsx, destructure lang from params:

export default async function RootLayout({
  params,
  children,
}: {
  params: Promise<{ lang: string }>;
  children: React.ReactNode;
}) {
  const { lang } = await params;
  // use lang...
}

Navigate to any URL that triggers a 404 (e.g. /en/nonexistent-page)
The layout crashes because params is undefined

Expected behavior

renderHTTPAccessFallbackPage should pass params: makeThenableParams(params) to layout components, matching the normal render path.

Workaround

Add nullish coalescing when destructuring params in layouts:

const { lang } = (await params) ?? {};

Environment

vinext: ^0.0.22
next: 15.5.2

Originally created by @Jbithell on GitHub (Mar 8, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/346 `renderHTTPAccessFallbackPage` does not pass `params` to layout components --- When vinext renders HTTP access fallback pages (404, 403, 401), layout components are rendered without the `params` prop, causing layouts that destructure route params to crash with: ``` Cannot destructure property 'lang' of '(intermediate value)' as it is undefined. ``` ## Root cause In the bundled output, `renderHTTPAccessFallbackPage` creates layout elements with only `{ children }` and no `params`: ```js // renderHTTPAccessFallbackPage path — no params passed const LayoutComponent = layouts[i3]?.default; if (LayoutComponent) { element = createElement(LayoutComponent, { children: element }); } ``` The normal render path correctly passes params: ```js // normal render path — params passed correctly const layoutProps = { children: element, params: makeThenableParams(params) }; ``` This affects both the RSC and non-RSC branches within `renderHTTPAccessFallbackPage`. ## Reproduction 1. Create a Next.js app with a dynamic `[lang]` route segment 2. In `app/[lang]/layout.tsx`, destructure `lang` from `params`: ```tsx export default async function RootLayout({ params, children, }: { params: Promise<{ lang: string }>; children: React.ReactNode; }) { const { lang } = await params; // use lang... } ``` 3. Navigate to any URL that triggers a 404 (e.g. `/en/nonexistent-page`) 4. The layout crashes because `params` is `undefined` ## Expected behavior `renderHTTPAccessFallbackPage` should pass `params: makeThenableParams(params)` to layout components, matching the normal render path. ## Workaround Add nullish coalescing when destructuring params in layouts: ```ts const { lang } = (await params) ?? {}; ``` ## Environment - vinext: `^0.0.22` - next: `15.5.2`

BreizhHardware closed this issue

2026-05-06 12:37:03 +02:00

BreizhHardware commented

2026-05-06 12:37:05 +02:00

Author

Owner

@james-elicx commented on GitHub (Mar 8, 2026):

I've had the fix for this sat in the big batch of fixes i made for another project. Slowly sifting through them this weekend and trying to make repros for each one before merging...

@james-elicx commented on GitHub (Mar 8, 2026): I've had the fix for this sat in the big batch of fixes i made for another project. Slowly sifting through them this weekend and trying to make repros for each one before merging...

BreizhHardware referenced this issue

2026-05-06 12:39:01 +02:00

[PR #79] [MERGED] fix(navigation): cache getServerSnapshot fallback in useSearchParams #292