Link to the code that reproduces this issue
https://github.com/amannn/nextjs-bug-repro-rootparams-caching
To Reproduce
npm install && npm run build && npm startnpm run slow in a second terminal- Open http://localhost:3300/en. Every line says
en.
- Click
de in the nav.
- The URL is
/de, the pathname line and the layout line say de, but the page line still says en.
Two conditions are needed beyond the app itself. A production build, since this does not happen in next dev. And network latency, since the bug is a race between a navigation and the prefetch it starts; any deployed app has this, a local next start does not. The repository includes a proxy that adds 500ms to RSC responses, so no devtools throttling is needed.
See also the repro readme for details.
Current vs. Expected behavior
Current: after the navigation, the page segment keeps rendering the locale of the previous URL, while the layout above it and the pathname reported by the client router both update.
Expected: a client-side navigation that changes a root param should not reuse a segment rendered for a different value of that param. Every line should agree, as it does on a full page load.
Reading params in the affected segment avoids it, even when the value is never used, which is the only difference between the failing page and the workaround page.
Provide environment information
Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 25.6.0: Fri Jul 31 19:19:08 PDT 2026; root:xnu-12377.161.14~5/RELEASE_ARM64_T6050
Available memory (MB): 24576
Available CPU cores: 18
Binaries:
Node: 26.5.0
npm: 11.17.0
Yarn: 1.22.22
pnpm: 10.32.1
Relevant Packages:
next: 16.4.0-canary.22
eslint-config-next: N/A
react: 19.2.8
react-dom: 19.2.8
typescript: 5.9.3
Next.js Config:
output: N/A
Which area(s) are affected? (Select all that apply)
cacheComponents
Which stage(s) are affected? (Select all that apply)
next start (local), Vercel (Deployed)
Additional context
Also reproduces on 16.3.4.
Three things narrow it down:
- The locale links carry
prefetch={false}. With the default eager prefetching it does not reproduce, even with latency.
- Navigating with
useRouter().push instead of <Link> does not reproduce it.
- A segment that is not
"use cache" and reads next/root-params is always correct.
Which segment goes stale seems to depend on cache and prefetch ordering rather than on the kind of segment. In the reproduction it is reliably the page, while the layout stays correct. In the user report this came from, it was the layout that went stale while the page updated.
prefetch={false} on links that change the locale is what next-intl emits, so this reached us through a user report: amannn/next-intl#1627 (comment)
Link to the code that reproduces this issue
https://github.com/amannn/nextjs-bug-repro-rootparams-caching
To Reproduce
npm install && npm run build && npm startnpm run slowin a second terminalen.dein the nav./de, the pathname line and the layout line sayde, but the page line still saysen.Two conditions are needed beyond the app itself. A production build, since this does not happen in
next dev. And network latency, since the bug is a race between a navigation and the prefetch it starts; any deployed app has this, a localnext startdoes not. The repository includes a proxy that adds 500ms to RSC responses, so no devtools throttling is needed.See also the repro readme for details.
Current vs. Expected behavior
Current: after the navigation, the page segment keeps rendering the locale of the previous URL, while the layout above it and the pathname reported by the client router both update.
Expected: a client-side navigation that changes a root param should not reuse a segment rendered for a different value of that param. Every line should agree, as it does on a full page load.
Reading
paramsin the affected segment avoids it, even when the value is never used, which is the only difference between the failing page and the workaround page.Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 25.6.0: Fri Jul 31 19:19:08 PDT 2026; root:xnu-12377.161.14~5/RELEASE_ARM64_T6050 Available memory (MB): 24576 Available CPU cores: 18 Binaries: Node: 26.5.0 npm: 11.17.0 Yarn: 1.22.22 pnpm: 10.32.1 Relevant Packages: next: 16.4.0-canary.22 eslint-config-next: N/A react: 19.2.8 react-dom: 19.2.8 typescript: 5.9.3 Next.js Config: output: N/AWhich area(s) are affected? (Select all that apply)
cacheComponents
Which stage(s) are affected? (Select all that apply)
next start (local), Vercel (Deployed)
Additional context
Also reproduces on 16.3.4.
Three things narrow it down:
prefetch={false}. With the default eager prefetching it does not reproduce, even with latency.useRouter().pushinstead of<Link>does not reproduce it."use cache"and readsnext/root-paramsis always correct.Which segment goes stale seems to depend on cache and prefetch ordering rather than on the kind of segment. In the reproduction it is reliably the page, while the layout stays correct. In the user report this came from, it was the layout that went stale while the page updated.
prefetch={false}on links that change the locale is whatnext-intlemits, so this reached us through a user report: amannn/next-intl#1627 (comment)