RSC payload served from browser disk cache after router cache is cleared by a mutation

[VladSmirnou]

Config:

• next.js 16.3.0
• cacheComponents and partialPrefetching are enabled
• browser is Chrome Version 151.0.7922.138.
• I built the application with 'next build' and run with 'next start'

The problem is:

Let's say I'm on a route '/todolist' which displays a todolist that includes a couple of todolist items, fetched from the database using a 'use cache' cached function which assigns a tag 'todolist' to this cache. I do a soft navigation from the '/todolist' to the '/todolist/[id]' route in order to update the todolist item via a server action, and then I do updateTag('todolist') at the very end of it. I'm using a client-side form component, so I do a redirect back with router.push('/todolist') inside an event handler after a successfull mutation. It works exactly once, because after the first mutation the browser caches the previous router.push('/todolist') server 'rsc' response. So from now on I have this sequence of events, I guess:
server action (success) -> router.push('/todolist') call -> event handler is done running / urgent state updates are finished -> router cache is being purged due to the updateTag call (link prefetching starts, if any) -> soft-navigation to the '/todolist' route -> browser requests the '/todolists' page from the server checking its cache first, and finding the previously cached 'rsc' in there (I see Status Code 200 OK (from disk cache) for this request) -> 'rsc' is being stored in the router cache -> I see unupdated todolist after the navigation.

What fixes this issue:

• page refresh / hard navigation to the '/todolist' route, so the updated full router cache is actually reached
• disabling the browser cache on the network tab
• manually assigning specific 'cache-control' headers in headers() / proxy for this route when a 'rsc' request is comming
• using revalidatePath('/todolist') + redirect('/todolist') in the server action instead of the previous setup. I don't know why this works either, in this context calling revalidatePath and updateTag must have no difference, and calling redirect from the server action also just makes a client-side navigation after the promise rejects in the event handler. The only difference that I spotted is that server response that happens after the navigation with revalidatePath('/todolist') + redirect('/todolist') doesn't have a 'stale-while-revalidate' header. I'm not a huge browser cache expert, so I cannot tell if this is the root of the problem or not

The questions are:

• Why my initial setup with updateTag + router.push doesn't work properly?
• How is updateTag + router.push different from the revalidatePath + redirect combination?
• How does a request reaches the server and triggers full router cache revalidation with updateTag + router.push when the browser gets a cached response from the disk cache? is it some soft of SWR but in the browser itself?

[icyJoseph]

I've been able to repro this, let me do a bit more of triaging, I'll share it internally too.

[icyJoseph]

An update here, we'll soon have a fix for this, there's some triaging and testing going on.

[VladSmirnou]

Hi! That's great news, thanks for the update!

[gitsult4n]

Likely cause: updateTag invalidates the Next.js server data cache and the client router cache, but it doesn't change the HTTP Cache-Control header on the RSC response for that route. So the browser's own HTTP disk cache (a separate layer from Next's router cache) still matches the identical RSC request URL and serves the stale body, even though Next's internal caches were invalidated. revalidatePath + redirect likely marks the route dynamic with a different Cache-Control (no stale-while-revalidate), which makes the browser skip its disk cache. Workaround options: set an explicit Cache-Control: no-store on the RSC response for this route, or keep using the revalidatePath + redirect combo you already found. Worth filing as a bug if there isn't one already — the interaction between cacheComponents and browser HTTP caching doesn't seem documented.

[paramjeetn]

The difference in behavior comes down to how browser HTTP caching interacts with Next.js Client Router Cache versus Server Action redirects:

1. Why updateTag + router.push('/todolist') hit stale browser cache:

When you perform a soft client-side transition via router.push('/todolist') in an event handler after an action, Chrome checks its local HTTP disk cache for the .rsc payload first. If the previous response was cached with standard cache-control headers, the browser answers with 200 OK (from disk cache) before reaching the server's purged cache.

2. Why revalidatePath + redirect('/todolist') inside the Server Action works:

When a Server Action completes with redirect(), Next.js responds with an action response header containing the revalidated RSC flight payload directly in the action's response stream. The client router applies the updated payload immediately without initiating a separate GET request to the browser's HTTP disk cache.

Recommended Pattern:

For mutations, prefer performing the redirect directly inside the Server Action:

// In your server action:
'use server'

import { revalidateTag } from 'next/cache'
import { redirect } from 'next/navigation'

export async function updateTodo(formData: FormData) {
  await db.update(...)
  revalidateTag('todolist')
  redirect('/todolist')
}

Or if redirecting on the client, call router.refresh() right before router.push() to force the router to bypass the client-side RSC cache.

[satiricalguru]

Here is the breakdown of what is happening under the hood with Next.js 16, the browser disk cache, and why redirect() behaves differently from router.push().

---

1. Why updateTag + router.push fails with (from disk cache)

There are two separate cache layers at play:

1. The Client Router Cache (In-Memory): Managed by Next.js in JavaScript runtime memory.
2. The Browser HTTP Cache (Disk / Memory Cache): Managed by Chrome according to HTTP Cache-Control headers.

When your server action completes with updateTag('todolist'), the server-side Cache Components layer successfully marks that cache entry as stale.

When your client code then runs router.push('/todolist'):

• Next.js purges its Client Router Cache for /todolist and issues a fetch request for the route's RSC payload (_rsc payload).
• However, when the browser network layer handles this standard GET request, it checks Chrome's HTTP disk cache first.
• Because the route previously returned an HTTP Cache-Control header (such as s-maxage or stale-while-revalidate), the browser determines the disk-cached RSC payload is still valid and intercepts the request before it hits the server/network, returning 200 OK (from disk cache).
• Next.js receives this stale disk-cached RSC payload and loads it into the Router Cache, resulting in the stale UI.

---

2. How updateTag + router.push differs from revalidatePath + redirect

When you use redirect('/todolist') inside a Server Action:

• The Server Action executes as an HTTP POST request.
• Instead of returning a standard response and delegating the navigation to a separate client GET request, Next.js intercepts the server action redirect on the server.
• The server generates the updated RSC payload for the target route (/todolist) in the same execution context and sends it directly in the Server Action response payload.
• Server Action responses always carry Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate.
• Because HTTP POST responses are not served from the browser's static GET disk cache, Chrome never intercepts it with a cached payload, and the client router receives the fresh state directly.

---

3. Recommendations & Solutions

1. Use Server Action Redirects for Post-Mutation Navigation (Recommended):
   Calling redirect('/todolist') from within the Server Action is the canonical App Router pattern for mutations because it guarantees atomic mutation + cache revalidation + fresh RSC delivery in a single roundtrip without client-side race conditions.

2. If You Must Navigate on the Client via router.push:
   Ensure your server/proxy or middleware does not emit long-lived HTTP caching headers (like stale-while-revalidate) on dynamic RSC responses for routes that undergo frequent mutations. Dynamic routes should return Cache-Control: private, no-store to prevent Chrome from intercepting client-side navigation fetches.