router.push after an awaited Server Action commits as replaceState, but only in deployed environments (16.2.10 and 16.3.5)

[allandt-numan]

Summary

A programmatic router.push() that runs after an awaited Server Action commits to browser history as a replace instead of a push, so the Back button skips that page. It only happens in deployed environments — it never reproduces locally in any configuration we tried, including a local production build.

We could not produce a minimal public reproduction, which is why this is a discussion rather than an issue. What we do have is a controlled environment matrix, a same-infrastructure Next 15 control, and what we believe is the exact line responsible. It matches withdrawn issue #89802 almost exactly; that reporter closed their own issue saying their repro didn't work, so as far as we can tell this has never been triaged.

Symptom

In a Next.js App Router page, a click handler does roughly this:

const handleContinue = async () => {
  const result = await updateSubscription(subscriptionId, variantId) // Server Action
  const nextRoute = computeRoute(result)
  router.push(nextRoute)
}

Deployed, the navigation happens and the URL is correct, but no history entry is created. Pressing Back skips the page entirely and lands on whatever preceded it.

Measured with a Navigation API listener rather than history.length (which is capped at 50 in Chrome and can't distinguish push from replace):

navigation.addEventListener('navigate', (e) => {
  console.log('→', e.destination.url, '| type:', e.navigationType)
})

• Working (Next 15): type: push, then type: replace to the same URL (normal), and Back produces type: traverse back to the previous page.
• Broken (Next 16): type: replace, type: replace. No push at all. Back skips the page.

The broken navigation also issues three RSC fetches for a single navigation, where the working one issues one.

Evidence matrix

Same application code, same user journey, same click, varying only the environment and framework version:

Environment	Framework	Result
next dev, direct	16.2.10 / React 19.2.7	push ✅
next dev, behind local reverse proxy	16.2.10	push ✅
next build + next start, direct	16.2.10	push ✅
next build + next start, behind local reverse proxy	16.2.10	push ✅
Deployed review environment	15.5.16 / React 18.3.1	push ✅ (Back traverses correctly)
Deployed review environment	16.2.10 / React 19.2.7	replace ❌
Deployed staging environment	16.2.10 / React 19.2.7	replace ❌

The Next 15 row is the important control: same deployment infrastructure, same Kubernetes setup, same reverse proxy, same latency — only the framework version differs.

Also unaffected everywhere, including on the same broken page:

• startTransition(() => router.push(url)) in a click handler that performs no mutation beforehand.
• next/link navigation.

We first assumed the shape of the dispatch mattered, and it does not. We deployed a build in which the failing handler was rewritten to await the Server Action and then call startTransition(() => router.push(url)) — the same form as the working call sites above — and it still committed as replace. We also tested the original startTransition(async () => { await …; router.push() }) form in the same environment, with the same result.

So the distinguishing factor is not the transition style, the route, or the handler shape. It is whether a mutation happens between the destination being prefetched and the navigation being made.

Suspected cause

dispatchRetryDueToTreeMismatch in client/components/router-reducer/ppr-navigations.js decides the history intent for a retry with:

const lastCommitted = getLastCommittedTree()
const retryNavigateType =
  lastCommitted !== null && baseTree !== lastCommitted ? originalNavigateType : 'replace'

Next's own comment above it reads:

If the original navigation hasn't committed to the browser history yet (the transition suspended before React committed), inherit its push/replace intent. Otherwise, the pushState already ran, so use 'replace' to avoid creating a duplicate history entry.

TODO: Ideally this check would happen right before we schedule the React update (i.e., closer to where the action is dispatched into the queue), not here where the action is constructed.

When that heuristic goes the wrong way, the original push intent is discarded, ACTION_SERVER_PATCH is dispatched with navigateType: 'replace', pushRef.pendingPush ends up false, and HistoryUpdater in app-router.js takes the else branch and calls replaceState.

Why an awaited Server Action would trigger it: the destination is prefetched before the mutation and requested dynamically after it, so the prefetched tree and the dynamic response genuinely differ and the retry path runs. That also explains the three RSC fetches (the retry, plus invalidateRouteCacheEntries re-prefetching visible links) and why it never reproduces locally, since next dev doesn't prefetch the same way.

We have not directly observed the mismatch firing — we inferred it from the retry's fetch signature plus the code path — so treat this part as a strong hypothesis rather than confirmed.

Version check

We diffed dispatchRetryDueToTreeMismatch between 16.2.10 and 16.3.5. 16.3.5 adds a retryFreshnessPolicy parameter and changes discoverKnownRoute's signature, but the retryNavigateType line is byte-identical. Upgrading does not fix it.

Ruled out by experiment

• Application code — reproduced on a commit predating any of our attempted fixes; several rewrites of the handler changed nothing.
• startTransition usage around the push — async and sync forms both tested in the affected deployment, both replace.
• The destination route — two different destinations behave the same.
• Build mode — a local production build pushes correctly.
• Reverse proxy — a local production build behind a proxy pushes correctly.
• Request latency — the Server Action takes ~786ms and the whole sequence ~3s, well inside Chrome's transient activation window.
• Cookies set by proxy/middleware on the request.

Environment

Next.js:      16.2.10 (also verified unchanged in 16.3.5)
React:        19.2.7 / react-dom 19.2.7
Node:         22.22.0
Router:       App Router
Deployment:   self-hosted, `next start` in containers on Kubernetes behind Envoy/Istio
Config:       cacheComponents / PPR / reactCompiler / viewTransition all OFF
Browser:      Chrome (Navigation API used for measurement)

Notably cacheComponents is not enabled here, whereas #89802's reproduction required it. If the retry path is reachable without Cache Components, that would widen the scope beyond what that issue described.

What would help

1. Is retryNavigateType falling back to 'replace' the expected behaviour when the original push has not yet committed, and should the original intent be preserved unconditionally?
2. Is there a supported way to observe when dispatchRetryDueToTreeMismatch fires, so we can confirm rather than infer? A dev-only warning would have saved us a lot of time here.
3. Is there a recommended pattern for "mutate, then navigate" that avoids the prefetch/dynamic tree mismatch — short of disabling prefetch on the destination or navigating before the mutation completes?

Happy to run further instrumentation on the affected deployment, or to try a patched build, if that helps narrow it down.

Related

• router.push() creates replaceState instead of pushState when PPR tree mismatch triggers ACTION_SERVER_PATCH #89802 — router.push() creates replaceState instead of pushState when PPR tree mismatch triggers ACTION_SERVER_PATCH. Same symptom and same suspected line; closed by its own reporter because their reproduction stopped working, so it was never triaged.

[allandt-numan]

Note: co-written with claude but it all checks out and should pretty readable

[allandt-numan]

updated with a clarification around startTransition and additional information about attempts to solve

[rachel11026725]

• • @

[patelved3313]

Your analysis looks solid. This seems much more like a Next.js retry/history issue than an application-level router.push() problem.

As a temporary workaround, I’d move the navigation into the Server Action itself:

import { redirect } from 'next/navigation'

// after the mutation
redirect(nextRoute)

redirect() is the supported pattern after a Server Action mutation, and it defaults to a push history entry in Server Actions.

Your Next 15 vs Next 16 test on the same infrastructure is also strong evidence that this is framework-related.

If redirect() avoids the issue in the affected deployment, that would be another useful data point confirming the client-side retry path is involved.

If this helps, please consider marking it as the accepted answer.

[GautamVhavle]

I cannot reproduce the production-only Next 16 history bug from here, but your Next 15 vs 16 matrix on the same deploy is already the strongest evidence this is framework history, not the click handler.

For a mutation that should become a new history entry, the App Router pattern that is actually specified is to navigate inside the Server Action:

'use server'
import { redirect } from 'next/navigation'

export async function updateSubscription(...) {
  // ...write...
  redirect(nextRoute) // history push from the action
}

If redirect() pushes correctly on the broken deploy, you have isolated it to client router.push after await of the action.

If the next route depends on the action result, keep that logic in the action and redirect() the computed URL. Mixing await action() and then router.push() in the same click handler is the shape that races Next 16's refresh/retry history (you already measured three RSC fetches vs one).

I have not run 16.2.10 or 16.3.5 on a Vercel-like deploy. If redirect() still replaces in that environment, it belongs on an issue with a deploy repro. The discussion already has enough signal that this is not an app-level history.pushState mistake.

[omid-io]

Your reading of dispatchRetryDueToTreeMismatch is right on the money.

Why only in deployed environments

In next dev, link prefetching skips the full PPR router cache lifecycle. In production, prefetching dynamic segment boundaries populates the client router cache. When your Server Action mutates data, it dirties cache tags on the server, but the client still holds the prefetched tree. When router.push runs, React spots the mismatch between the prefetched cache and the fresh RSC stream, hitting dispatchRetryDueToTreeMismatch.

Because baseTree === lastCommitted evaluates to true during that retry pass, the reducer assumes the history transition already ran and falls back to 'replace' to avoid duplicate entries.

---

Answering your questions

1. Is falling back to 'replace' expected?
   It is a defensive heuristic meant for concurrent React 19 microtask retries (so an interrupted transition does not double-push). But when the retry is caused by a post-mutation tree mismatch, it falsely treats the original push as already committed. This is an edge-case bug in the reducer logic that should preserve originalNavigateType.

2. Observing it directly:
   Outside monkeypatching history.pushState / history.replaceState and checking RSC network waterfall signatures (3 fetches + replace without push), Next currently provides no dev-mode telemetry or warning when this branch fires.

3. Recommended workaround:
   Instead of await action() then router.push(), the cleanest path that sidesteps the client tree mismatch completely is using redirect() inside the Server Action:

'use server'
export async function updateSubscription(id: string, variantId: string) {
  // mutate...
  const nextRoute = computeRoute(...)
  redirect(nextRoute) // Next handles the 303 redirect with a clean push navigation
}

If you must trigger navigation client-side, refreshing the router cache before pushing avoids the mismatch:

startTransition(async () => {
  await updateSubscription(subscriptionId, variantId)
  router.refresh()
  router.push(nextRoute)
})

[icyJoseph]

I've been trying to repro this, as a means to investigate further of course. My agents falsified a bunch of possible triggers, and I've got some follow ups:

• How is HTTP/2 terminated in your setup? Is Envoy speaking h2 all the way to Node, or is it h2 to the browser and h1 between Envoy and the app?
• Any revalidatePath() / revalidateTag() running around this flow?
• Is updateSubscription the first navigation, or has the user already navigated within the app before clicking?
• Does the action return early with redirect() or notFound() in any code path?
• Custom router.push wrapper (e.g. next-intl, next-safe-action, custom useTransition)?
• Proxy in play (rewrites, cookies-mutating auth)?
• Does the target route have a parallel/intercepted route (@modal, (.)…)?
• How often does this repro? When that heuristic goes the wrong way?
• DevTools Network: is the failing nav a document, fetch, or a stalled RSC?
• Same behavior in an incognito window / with all extensions off?

Note that a bunch of these come from a couple of agentic chats, where the context is not necessarily the initial input — in case they don't make so much sense to you

[nisargpatel7042lva]

Why this happens

When an awaited Server Action completes, Next.js automatically triggers a client-side reconciliation / soft-refresh to sync the UI with updated Server Components.

If you call router.push() while that reconciliation transition is still pending, the transitions conflict. The pending Server Action state update takes precedence or overrides the push transition, causing the browser navigation to collapse into a replaceState-like behavior in deployed environments.

---

Solution 1: Use redirect() inside the Server Action (Recommended)

Handling the redirect directly on the server is the most idiomatic pattern in Next.js:

// app/actions.ts
'use server';

import { redirect } from 'next/navigation';

export async function submitForm(formData: FormData) {
  // ... your mutation or database operations
  
  redirect('/target-page'); // Next.js handles the redirect header cleanly
}

Solution 2: Wrap router.push() in startTransition

If you must trigger the navigation from the client (e.g., inside an event handler), wrap router.push() in React's startTransition so it waits for the Server Action's internal state updates to settle:

'use client';

import { useRouter } from 'next/navigation';
import { useTransition } from 'react';
import { submitForm } from './actions';

export function MyComponent() {
  const router = useRouter();
  const [isPending, startTransition] = useTransition();

  async function handleSubmit() {
    await submitForm();

    startTransition(() => {
      router.push('/target-page');
    });
  }

  return (
    <button onClick={handleSubmit} disabled={isPending}>
      {isPending ? 'Submitting...' : 'Submit'}
    </button>
  );
}

[allandt-numan]

Thanks for the input guys - i'm going to test a couple of the ideas here:

• redirect() - adding this in the updateSubscription server action. We currently have a couple of analytics tracking events after the update so would take a minor re-order to make work
• router.refresh() + router.push() on the client side

@icyJoseph Thanks for the questions - i'll answer what I can but I'll also need to check a couple of things with the devops guys before i do - should be tomorrow

[allandt-numan]

Thanks for digging into this @icyJoseph — answers to all of your questions below, plus two new results since I posted, one of which rules out a workaround that's been suggested a few times in this thread.

Answers

1. How is HTTP/2 terminated?

h2 terminates at Cloudflare, and it's HTTP/1.1 from there on. Our platform team confirmed this from the load balancer logs rather than just the config:

• Cloudflare opens a separate HTTP/1.1 connection to our Google load balancer.
• The LB talks plain h1 to Envoy on port 80, so Envoy never receives h2 at all.
• Envoy does use h2c to the app's sidecar, but the sidecar hands it to Node as h1.

So no, Envoy is not speaking h2 to Node — and next start on a Node HTTP server wouldn't accept it natively in any case.

2. Any revalidatePath() / revalidateTag() around this flow?

Not in the action itself — it's a plain PATCH to our BFF with no cache APIs involved.

There is one nearby that I think is worth your attention though. The destination page has a mount effect that can call a server action which sets a cookie and calls revalidatePath(pathname). It's conditional (only when a previously stored coupon is present), but when it does fire it's on the destination's mount — so it can overlap with the history commit of the navigation we're investigating.

3. Is it the first navigation, or has the user already navigated within the app?

I tested both, and it fails either way:

• The user arrives at the first page via a full document load from a separate app, so the first failing navigation is indeed the first client-side navigation in that document.
• But I then continued forward through a second client-side navigation in the same document, from a different component, also following an awaited action. It replaced too.

So "first navigation in the document" is not the factor.

4. Does the action return early with redirect() or notFound()?

No. It returns a normal response. The target route has no redirect() or notFound() either.

5. Custom router.push wrapper?

No. Plain useRouter from next/navigation. We use next-intl, but for translations only — no createNavigation or shared-pathnames wrapper.

6. Proxy in play (rewrites, cookies-mutating auth)?

Yes, and this is the answer I'd most want a second opinion on. We run a middleware chain on every matching request: CSP headers, affiliate capture, tracking, auth, a second auth pass, subscription, and a coupon resolver. Three of those set cookies on the response, and the coupon one also passes a modified request down the chain. Auth can redirect.

So: cookie-mutating middleware runs on the RSC requests involved in these navigations.

7. Parallel or intercepted routes on the target?

No. No @slot or (.) directories anywhere in the app.

8. How often does this reproduce?

Deterministic — 100% in every deployed environment, 0% locally. Not intermittent. My "when the heuristic goes the wrong way" phrasing in the original post was me reading the source, not describing flakiness. Sorry for the ambiguity.

9. Network: document, fetch, or stalled RSC?

fetch, and not stalled. A single failing navigation issues three RSC fetches to the destination URL — 748ms, 833ms and 460ms, all 200. The working Next 15 control issues one.

10. Incognito / extensions off?

Same behaviour. Tested in a Chrome incognito window with extensions disabled, and separately in Firefox — the history entry is replaced rather than pushed in both. So it isn't extension interference, and it isn't Chrome-specific.

Two new results

Three consecutive mutating navigations all lose their history entry. On a freshly loaded page I went through three steps, each one awaiting a server action and then calling router.push, across two different components. Pressing Back at the end skipped all of them and landed on the page before the sequence started. So it isn't specific to one component, one route, or the first navigation in a document.

Wrapping the push in startTransition does not help — we've shipped and measured it. This has been suggested a few times in the thread, so to save anyone else the effort: we deployed exactly this shape

async function handleContinue() {
  await updateSubscription(...)          // Server Action, awaited
  startTransition(() => {
    router.push(nextRoute)               // sync callback, after the await
  })
}

to the affected environment and it still committed as replace. We also tested the original form, with the await inside an async startTransition callback, in the same environment — same result. The dispatch shape makes no difference; what matters is that a mutation happened between the destination being prefetched and the navigation being made.

That also makes me doubt the "the push collides with the action's pending reconciliation" explanation offered upthread, since deferring the push until after the action settles is exactly what that variant does.

On redirect()

This is the one suggestion still genuinely untested, and I can see why it might work — the navigation would be driven by the action's own response rather than a client navigation consulting a stale prefetch cache.

It isn't a drop-in for us, though, for two reasons worth mentioning in case they're common:

1. The destination is computed client-side, from props the action doesn't have. Workable by passing the route into the action, but it moves the decision.
2. redirect() throws, so the action never returns — and our analytics calls run client-side after it resolves, using its result. They'd simply stop firing. We'd have to move them before the action or server-side, which changes their consent behaviour.

Happy to try it if you think it's diagnostically useful rather than just a workaround, but I didn't want to report "redirect() fixes it" as if it were equivalent, when it changes where both the routing decision and the analytics live.

Environment (unchanged)

Next.js    16.2.10  (retry logic verified byte-identical in 16.3.5)
React      19.2.7 / react-dom 19.2.7
Node       22.22.0
Router     App Router
Deploy     self-hosted, `next start` in containers on Kubernetes behind Envoy/Istio, Cloudflare in front
Config     cacheComponents / PPR / reactCompiler / viewTransition all OFF

Happy to run more instrumentation on the affected deployment, or a patched build with logging in the retry path if that would help — we can reproduce it on demand, we just can't reproduce it locally.

[icyJoseph]

Awesome! Thanks, well for what is worth I managed to get a false positive (rolled a few agents to try and repro), upon closer inspection it was wrong.

I guess one thing we are narrowing into is that the payload could somehow be delivered in a race condition where two _rsc requests fire, or an assumption is broken in the payload delivery.

Are you able to reach your origin? Like you know you have CF and other layers in front of the Next.js server, can you reach the Next.js server directly? Does it repro when you do that? You are absolutely sure this doesn't repro with build+start locally right?

I've also never asked about next.config flags, anything going on there?

[allandt-numan]

@icyJoseph we found it. Thanks for the questions, the one about proxies and cookie-mutating middleware is what got us there.

What's happening

Our middleware chain includes a tracking middleware that records a page view on every matching request, and it rewrites a session_info cookie each time. It was also running on server action POSTs.

In 16.2.10, when middleware sets a cookie on an action request, mergeMiddlewareCookies (server/async-storage/request-store.js) copies it into requestStore.mutableCookies with .set(). That marks it as modified, so getModifiedCookieValues in action-handler.js counts it as a cookie mutation and the response carries X-Action-Revalidated: 1.

The action is a read-only PATCH to our BFF. It doesn't call cookies().set(), revalidatePath or revalidateTag. The server still responds with:

Set-Cookie: session_info=<redacted>; Path=/; Max-Age=1800; SameSite=lax
X-Action-Revalidated: 1

On the client, the server-action reducer sees that header, clears the whole prefetch cache, and starts a refresh navigation of the current page. Our router.push then runs while that refresh is still in flight, and the push loses its history entry. That also explains the extra RSC fetches.

The workaround on our side

We skip the tracking middleware for server action requests:

export const trackingMiddleware =
  (middleware: CustomMiddleware) =>
  async (request: NextRequest, event: NextFetchEvent, response: NextResponse) => {
    // WORKAROUND
    // Tracking writes the session cookie, and Next treats any cookie set by middleware on a server
    // action request as a mutation. It responds with X-Action-Revalidated, and the client refresh
    // that follows races a router.push after the action, replacing its history entry instead of
    // pushing one. Once that's fixed upstream this guard is optional, but server action POSTs
    // aren't page views, so it's still worth keeping.
    if (request.headers.has('next-action')) {
      return middleware(request, event, response)
    }

    const analytics = new AnalyticsServer(process.env.API_URL, request, response)
    await analytics.init()
    analytics.trackPageView({ page_type: 'page' })
    return middleware(request, event, response)
}

On a review env with that change, the same POST has no Set-Cookie and no X-Action-Revalidated, and Back works again. As a bonus, x-envoy-upstream-service-time for the action dropped from 261ms to 36ms.

It works, but it relies on next-action, which I think is an internal header. It also means any middleware that sets cookies needs to know about server actions. So I'd still like your view on whether this is the intended behaviour.

Two corrections to what I posted earlier

1. The "never reproduces locally" rows are wrong, or at least unproven. Our local dev container had a stale node_modules volume and was still running Next 15.5.18. Its action responses showed the Next 15 header format, [[],0,1]. The cookie-revalidation flag is set there too, so the trigger was always present locally. I'm rechecking the local next build rows.
2. I'd stop looking at retryNavigateType. baseTree there is the destination tree, so the 'replace' fallback only fires after the push has already committed. It fits better that the original push is superseded by the refresh racing it.

Your other questions

• next.config: nothing experimental. It has output: 'standalone', assetPrefix: '/pf' outside dev, transpilePackages, images.remotePatterns, the next-intl plugin, static security headers via headers(), and withSentryConfig.
• Origin access: we didn't get to it, and it's probably moot now since the trigger is in our middleware and the Next runtime, not the network path.

What I'd still like your view on

1. Is it intended that a cookie set by middleware makes an action report X-Action-Revalidated? It looks like a side effect of mergeMiddlewareCookies reusing .set() on the mutable adapter. Any app with session or analytics cookies in middleware will turn every server action into a full client cache invalidation.
2. Even for an action that really does set a cookie, is it expected that a router.push straight after it commits as a replace? We have a real case of that (an action that writes a cookie before navigating) and would expect it to hit the same race.

I haven't run a standalone repro yet, but I'd expect this to be enough:

// middleware.ts
export function middleware() {
  const res = NextResponse.next()
  res.cookies.set('mw', Date.now().toString())
  return res
}

// actions.ts
'use server'
export async function noop() {
  return 1
}

// page.tsx (client)
await noop()
router.push('/next') // Back skips the current page

Happy to put that into a repo if it helps.

[allandt-numan]

i got claude to spin up this repro https://github.com/allandt-numan/next-action-cookie-history-repro but it's not validated

EDIT I ran the validation - it makes sense and gives an example of the cookie causing the bug

npm start && npm run test:history 

> test:history
> node check-history.mjs

action response: { 'x-action-revalidated': '1', 'set-cookie': 'mw=…' }
navigate events after A: [ 'replace -> /b', 'traverse -> /', 'replace -> /' ]
history.length: 3 -> 3
Back landed on: / (BUG: skipped /a)

now with skip action on

SKIP_ACTIONS=1 npm start && npm run test:history 

> test:history
> node check-history.mjs

action response: { 'x-action-revalidated': '(absent)', 'set-cookie': '(absent)' }
navigate events after A: [ 'push -> /b', 'traverse -> /a', 'replace -> /a' ]
history.length: 3 -> 4
Back landed on: /a (OK)