-
Notifications
You must be signed in to change notification settings - Fork 26.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calling headers()
in root layout breaks navigations while in 404 page
#61956
Labels
bug
Issue was opened via the bug report template.
linear: next
Confirmed issue that is tracked by the Next.js team.
locked
Comments
4 tasks
balazsorban44
added
the
linear: next
Confirmed issue that is tracked by the Next.js team.
label
Feb 13, 2024
ztanner
added a commit
that referenced
this issue
Feb 14, 2024
…nd (#62033) ### What When a global not found page is rendered, and when the not-found page or containing layout has a link with `prefetch: auto` back to the root page, the router would update the URL but not correctly swap out the not-found component with the page component. ### Why With auto prefetching (which is the default when `prefetch` is left unspecified on a link), the router will perform a partial prefetch on dynamic pages. This means it'll fetch the flight data _without_ React nodes and store it in the prefetch cache. On navigation, this is used to determine where we already have cached React nodes and where we need to trigger a lazy fetch to get new data. However, global not found pages are peculiar in that they will always contain a data path like: `['', { children: ['__PAGE__', {}] }]` since they are inserted at the root. This means that if there's also a page component that corresponds with the same path, the router will incorrectly think it already has cache node data for it. ### How During SSR when the `asNotFound` flag signals to the renderer that the component we're rendering is matching the global not-found page, we modify the segment key to be something unique so the data path won't collide with a top-level page. In [fc01c8e](fc01c8e) I added handling only on the server to modify the segment key. This still fixes the issue, but at the cost of triggering an MPA navigation on the client because it's treated as a root layout change In [69d5687](69d5687) I added client handling to not treat this special segment key as a root layout change, and to signal to the router it needs to refetch the data. This ensures we don't do an MPA navigation. Fixes #61956 Closes NEXT-2481 --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
bug
Issue was opened via the bug report template.
linear: next
Confirmed issue that is tracked by the Next.js team.
locked
Link to the code that reproduces this issue
https://github.com/panteliselef/nextjs-404-route-bug
To Reproduce
/
root via the<Link>
in the navbar, url changes but we still see the 404 pageCurrent vs. Expected behavior
From the 404 page, navigate correctly back to
'/'
.To see the expected behaviour
headers()
fromRootLayout
Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 22.6.0: Wed Jul 5 22:17:35 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T8112 Binaries: Node: 20.11.0 npm: 10.2.4 Yarn: 1.22.21 pnpm: 8.15.0 Relevant Packages: next: 14.1.0 eslint-config-next: 14.0.4 react: 18.2.0 react-dom: 18.2.0 typescript: 5.3.3 Next.js Config: output: N/A
Which area(s) are affected? (Select all that apply)
App Router
Which stage(s) are affected? (Select all that apply)
next start (local), Vercel (Deployed)
Additional context
I tested the app in next@14.1.0 and next@13.5.6, same issue in both
NEXT-2481
The text was updated successfully, but these errors were encountered: