nextjs - ✅(Solved) Fix Browser back/foward doesn't rerun component code [1 pull requests, 5 comments, 6 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
vercel/next.js#91982Fetched 2026-04-08 02:01:54
View on GitHub
Comments
5
Participants
6
Timeline
13
Reactions
2
Author
Timeline (top)
commented ×5subscribed ×5issue_type_added ×1labeled ×1

PR fix notes

PR #92892: Fix dev mode hydration failure when page is served from HTTP cache

Description (problem / solution / changelog)

PR #88182 introduced an experimental option to use Cache-Control: no-cache instead of no-store in dev mode, and PR #91503 made it the default. With no-cache, browsers may serve the page from HTTP cache on back-forward navigation or tab duplication. The HTML, including the inline RSC payload, is restored from cache and all scripts re-execute.

In dev mode, React's Flight client uses a debug channel (a WebSocket-backed stream delivering component debug info) that adds dependencies to model chunk initialization. On a fresh page load, the WebSocket delivers this data and the dependencies resolve normally. On HTTP cache restore, however, the bootstrap script re-executes and creates a new debug channel stream, but the WebSocket doesn't re-send debug data for the cached payload's request ID. The debug dependencies are never fulfilled, blocking the entire model tree from initializing, so hydrateRoot is never called and the page loses all interactivity.

This is dev-only — production builds have no debug channel, so there are no stuck dependencies and no issue.

The fix buffers debug channel chunks in memory as they flow through the TransformStream in getOrCreateDebugChannelReadableWriterPair. Once all chunks have been received, the buffer is eagerly persisted to sessionStorage. When the page detects it was served from HTTP cache (via PerformanceNavigationTiming.transferSize === 0), createDebugChannel restores the debug data from sessionStorage and replays it as a synthetic ReadableStream instead of expecting it from the WebSocket. If the restore fails (e.g., quota exceeded during the earlier write, or the entry was overwritten by another page), the page falls back to location.reload() to get a fresh page from the server.

A regression test is included that navigates to an external page and verifies interactivity is preserved after clicking the browser back button. Tab duplication (which triggers the same HTTP cache restore) cannot be simulated in Playwright and was verified manually.

fixes #92238 fixes #91982 fixes #92687

Changed files

  • packages/next/src/client/dev/debug-channel.ts (modified, +115/-2)
  • test/e2e/app-dir/bfcache-regression/app/layout.tsx (added, +8/-0)
  • test/e2e/app-dir/bfcache-regression/app/page.tsx (added, +19/-0)
  • test/e2e/app-dir/bfcache-regression/bfcache-regression.test.ts (added, +41/-0)
  • test/e2e/app-dir/bfcache-regression/next.config.js (added, +6/-0)

Code Example

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro N
  Available memory (MB): 32699
  Available CPU cores: 16
Binaries:
  Node: 22.14.0
  npm: 10.9.2
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 16.2.1 // Latest available version is detected (16.2.1).
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: N/A
Next.js Config:
  output: N/A
RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/8sfnt3

To Reproduce

  1. Make sure you are on the "Start Dev Server" terminal so you can see console logs.
  2. In the preview, you should see the next.js home page. Notice in terminal there will be console log showing root layout and loading home.
  3. Add /project to the end of the urls and hit Enter (url should look like https://8sfnt3-3000.csb.app/project). You should see console log showing root layout and loading project.
  4. Then press the back button on your mouse or using alt + left arrow (windows) or cmd + left arrow (mac).
  5. Notice that there are no console logs. If you modify the project/page.tsx file and then go back to /project, it's still showing the previous version.

Current vs. Expected behavior

Current behavior is that component codes do not rerun when directly accessing a url and then using back and forward. I have codes like useEffect that needs to run to initialize the component.

Expected behavior should run the component's code like useEffect and other logic.

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro N
  Available memory (MB): 32699
  Available CPU cores: 16
Binaries:
  Node: 22.14.0
  npm: 10.9.2
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 16.2.1 // Latest available version is detected (16.2.1).
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: N/A
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Loading UI and Streaming

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

I back tested my reproduction on 16.2.1, 16.2.0, 16.2.0-canary.104, and 16.2.0-canary.103 where the issue was still occuring. 16.2.0-canary.102 is where the issue went away.

extent analysis

TL;DR

The issue can be potentially resolved by upgrading to a version of Next.js where the bug is fixed, as the issue is not present in 16.2.0-canary.102.

Guidance

  • The problem seems to be related to how Next.js handles navigation and component re-rendering when using the back and forward buttons.
  • To verify the issue, follow the steps provided in the "To Reproduce" section and check the console logs for the expected behavior.
  • Since the issue is not present in 16.2.0-canary.102, it's likely a bug that has been fixed in a newer version, but the exact version is not specified.
  • Consider testing with different versions of Next.js to find the exact version where the issue is resolved.

Example

No code snippet is provided as the issue seems to be related to a specific version of Next.js rather than a code-specific problem.

Notes

The issue might be specific to the development environment, as it's only reported to occur in "next dev (local)" mode. The exact version where the issue is fixed is not specified, but it's known to be resolved in 16.2.0-canary.102 or later.

Recommendation

Apply workaround by using a version of Next.js where the issue is known to be fixed, such as 16.2.0-canary.102 or later, as the exact fixed version is not specified. This is because the issue seems to be a bug that has been resolved in a newer version.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING