next.js: Crash when navigating back to a page using the browser's back button, after the page has been revalidated
Link to the code that reproduces this issue
https://github.com/jviide/my-minimal-nextjs-issue-reproduction
To Reproduce
The reproduction is also available at CodeSandbox: https://codesandbox.io/p/github/jviide/my-minimal-nextjs-issue-reproduction/main
- Install the repository dependencies with
npm i
and start the dev server withnpm run dev
. - Open the root page / on the browser.
- Click the link on the root page, taking you to the /foo page.
- Click the button on the /foo page. This submits the form and runs an action that calls
revalidatePath("/", "layout")
. - After the form has been submitted succesfully, navigate back to the root page / by using the browser’s back button.
- At this point the browser makes numerous GET requests to / which can be observed in the browser’s inspector.
- After some seconds (usually around 5 in my environment) the following error is shown: “Application error: a client-side exception has occurred (see the browser console for more information).”
Current vs. Expected behavior
When the browser’s back button is pressed after submitting the form, the root page at / should be opened.
Instead the browser makes a burst of GET calls to the root page (observable on the browser’s network inspector), failing after a while.
Provide environment information
Operating System:
Platform: linux
Arch: arm64
Version: #1 SMP Fri Jan 19 08:53:17 UTC 2024
Binaries:
Node: 20.11.0
npm: 10.2.4
Yarn: 1.22.21
pnpm: 8.15.0
Relevant Packages:
next: 14.1.1-canary.20 // Latest available version is detected (14.1.1-canary.20).
eslint-config-next: N/A
react: 18.2.0
react-dom: 18.2.0
typescript: N/A
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 dev (local), next start (local)
Additional context
The issue seems to reproduce more easily when root page’s data fetching is not instantaneous. The root page implementation simulates this by artificially sleeping for 500 milliseconds.
Tested on Chrome 121 and Safari 17.3 on macOS 14.3.
Next.js 14.0.0 was the earliest version I tested, and the issue also appears there.
Update: The issue can’t be reproduced with 14.0.5-canary.5, but can be reproduced with 14.0.5-canary.6.
About this issue
- Original URL
- State: closed
- Created 5 months ago
- Reactions: 20
- Comments: 27 (8 by maintainers)
Commits related to this issue
- fix router crash on revalidate + popstate (#62383) ### What When the popstate action is fired (as is the case in a browser back button), if the page you're going back to has missing cache node data... — committed to vercel/next.js by ztanner 4 months ago
- fix router crash on revalidate + popstate (#62383) When the popstate action is fired (as is the case in a browser back button), if the page you're going back to has missing cache node data, the route... — committed to vercel/next.js by ztanner 4 months ago
- fix for bug: https://github.com/vercel/next.js/issues/61336 — committed to Maciekek/shopping-list by deleted user 4 months ago
I’ve got a similar issue. Opening up your example in a normal browser window, going to
/foo
and hitting refresh (as opposed to submitting the form), then using the browser’s back button the application crashes with the following error messageThanks for the updated repro @jviide! I’ll reopen this for now while we investigate the cause
I tried with the following repository. https://github.com/yami-beta/nextjs-reload-back-issue
RSC Payload fetch seems to be looping when press browser’s back after reloading page.
https://github.com/vercel/next.js/assets/5106704/b2409b4a-9e0e-488b-9260-63c69a90bb0e
Amazing @ztanner, I thought I was going mad with this one. Cheers for the fix!
Actually loading.js is the only way that works for me atm. Gonna use loading till they fix this issue. Thanks!
Thank you, @ztanner! I can confirm that this fixes the issue in my environment as well.
Hype. Thank you @ztanner!
Hi there – thanks for the report. I just verified this against the latest canary and it seems to be resolved by #61687 (despite this reproduction being different, it appears to have the same underlying cause). Let me know if you’re still encountering this after upgrading and I can take another look! However I did check before/after that commit and noticed it only crashed in the before case.