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

  1. Install the repository dependencies with npm i and start the dev server with npm run dev.
  2. Open the root page / on the browser.
  3. Click the link on the root page, taking you to the /foo page.
  4. Click the button on the /foo page. This submits the form and runs an action that calls revalidatePath("/", "layout").
  5. 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.
  6. 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.

NEXT-2438

About this issue

  • Original URL
  • State: closed
  • Created 5 months ago
  • Reactions: 20
  • Comments: 27 (8 by maintainers)

Commits related to this issue

Most upvoted comments

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 message

Uncaught Error: async/await is not yet supported in Client Components, only Server Components. This error is often caused by accidentally adding 'use client' to a module that was originally written for the server.

Thanks 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!

I don’t know precisely why, but I’m guessing it’s some conflict with the client-side router cache trying to display content that has been purged and somehow running into a fetch loop.

By adding the loading.js file it somehow immediately falls back to the loading screen and stops the infinite loop.

All speculation, I have no understanding of the internals.

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.