App Router: soft navigation between different dynamic params reuses the committed shared-layout subtree without fetching the new RSC payload

[eashish93]

Summary

On soft navigation between two URLs that match the same shared dynamic layout but with different params (/projects/A → back → /projects/B), the client router reuses the committed subtree from /projects/A without fetching the RSC payload for /projects/B. The URL and <title> update to B, but everything rendered from the layout's server props (data fetched with A's param) remains A's. A layout-level key={param} does not help — the reused subtree is never re-rendered with fresh server output, so no new key is ever applied.

Repro

App-router app with a shared dynamic layout that fetches per-param data:

app/
  dashboard/page.tsx          // links to /projects/A and /projects/B
  projects/[pid]/layout.tsx   // async layout: fetches project by pid, renders client shell with it as props
  projects/[pid]/page.tsx

Steps (client-side navigation throughout, e.g. <Link> clicks + browser back):

1. Load /dashboard.
2. Click a link to /projects/A → renders A correctly.
3. Browser back to /dashboard.
4. Click a link to /projects/B.

Expected: /projects/B renders B's layout data (an ?_rsc fetch for /projects/B, or a fresh render of the layout with pid=B).

Observed: URL bar and <title> show B (metadata appears to refetch), but the rendered content is A's. The network panel shows no GET /projects/B?_rsc request at all for step 4 — the only activity is A's own subresources (in our app, an iframe still pointing at A's preview host). Reproduces both in vinext dev and consistently across pairs of params; order doesn't matter (B → back → A shows B under A's URL).

What we ruled out

• Server side is fine: when the ?_rsc request is issued (first visit to a pid, or hard load), the correct payload is returned.
• key={pid} on the layout's client child doesn't fix it — the committed subtree is reused as-is, so the fresh keyed render never applies.
• router.refresh() from a client guard "works" but races navigation: a popstate while the refresh's RSC stream is in flight hits abortSupersededNavigation → uncaught BodyStreamBuffer was aborted (stack below), and the stale subtree survives. Our current containment is a window.location.reload() when a client component sees useParams().pid disagree with its server props, which can't be superseded — but it's a full page load on every cross-param navigation into the route.

BodyStreamBuffer was aborted
  abortSupersededNavigation  vinext/dist/server/app-browser-entry.js:836:36
  navigateRsc                vinext/dist/server/app-browser-entry.js:843:4
  <anonymous>                vinext/dist/server/app-browser-popstate.js:29:49
  <anonymous>                vinext/dist/server/app-browser-entry.js:1181:3

(The useParams() context inside the reused subtree does update to B — only the server-rendered output is stale. That's what makes the client-side detection possible.)

Suspected area

Behaviorally this looks like the committed client cache / BFCache-style payload reuse treating the route pattern (/projects/[pid]) as the reuse key rather than the concrete URL, when the navigation goes dashboard → back → different param. Possibly related to the committed-payload reuse work (#2251) and history-entry restoration (#1366) — the back-traversal restores dashboard from cache, and the subsequent forward navigation to /projects/B appears to reuse /projects/A's committed entry instead of issuing a new RSC request.

Environment

• vinext 1.0.0-beta.1 (also reproduced on 0.2.0)
• vite 8.0.16, react 19.2.6, node 25.2.1, macOS (darwin 25.5.0)
• vinext dev targeting Cloudflare Workers (workerd via miniflare)

Happy to provide more traces or test a patch — this bites any app where per-param data flows through a shared dynamic layout (in ours, the layout binds a per-project WebSocket + iframe, so the wrong project's editor renders under the new URL).

[eashish93]

Follow-up with a repro repo: https://github.com/eashish93/vinext-2597-repro

Honest status: this synthetic app does not trigger the bug — on 1.0.0-beta.1 it always issues GET /projects/B?_rsc and renders B correctly. In our real app the bug still reproduces consistently on the same version, so the repro repo currently serves to document what's ruled out:

• Plain <Link> sequence /dashboard → /projects/A → back → /projects/B, both directions
• Repeat visits so both params sit in the visited-response cache
• Clicking the other param synchronously on popstate (the superseded-navigation race from the stack trace above)
• Async shared layout with per-param fetch (+400ms latency) passing data into a 'use client' shell as props
• Route groups with separate group layouts, loading.tsx in the dynamic segment, generateMetadata doing its own fetch

So plain committed-cache/visited-response reuse keyed by URL looks correct in isolation. From reading navigation-planner.js, the only reuse path keyed by route pattern rather than concrete URL appears to be the optimistic route shell (classifyNavigationReuse → attemptOptimisticRouteShell), which would match the symptom (stale layout subtree under the new URL, no ?_rsc fetch) if the follow-up authoritative fetch gets superseded/aborted. Remaining differences in our app that the repro doesn't model yet: nested sub-routes under [pid], link prefetching from a list panel, and heavy client work (iframe + WebSocket) in the layout shell.

Next I'll instrument app-browser-entry.js in our app to log the reuseDecision and rscUrl cache key at the classifyNavigationReuse call site during a live repro, and post the trace here. If there's a debug flag or trace sink you'd prefer we use for NavigationTrace, point me at it.

[eashish93]

One more symptom from the original closed-source app that may help narrow this down. The public repro linked above still does not reproduce it, so this is an additional diagnostic observation rather than a new repro claim.

The history-restoration problem also appears between sibling routes under the same dynamic layout and unchanged dynamic param:

1. Hard-load the dynamic route's index page.
2. Navigate through <Link> to a child route under the same dynamic layout.
3. Press browser Back.

Observed on vinext@1.0.0-beta.1:

• The address bar and restored server page correspond to the index route.
• A client component inside the shared layout still receives the child route's stale pathname from usePathname().
• In another traversal, the same valid index URL restored the app's notFound() UI. Hard-reloading the unchanged URL immediately rendered the correct page.
• Restarting the dev server cleared the already-bad history entry, but the mixed restoration behavior remained reproducible.

This suggests the committed history entry can restore a mixed tree even without changing the dynamic param: URL/server page from one route, client navigation state from another, and occasionally a stale notFound() result.

The reliable app-side containment is a hard reload on affected popstate traversals. router.refresh() is not safe as recovery here because a superseding history navigation can abort its RSC stream and surface BodyStreamBuffer was aborted.