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

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.

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.

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.

This looks less like a difference between updateTag() and revalidatePath() themselves, and more like an interaction between Next.js' router cache and the browser's HTTP cache for RSC responses.

updateTag('todolist') invalidates the tagged server-side cache entry and also causes the client router cache to be cleared. But when you then call router.push('/todolist'), Chrome can satisfy the RSC GET from its own disk cache before that request ever reaches the Next.js server. That would explain the 200 OK (from disk cache) and why you end up putting stale RSC data back into the router cache.

revalidatePath('/todolist') + redirect('/todolist') takes a different path through the Server Action lifecycle. The redirect is part of the action response, so Next.js can coordinate the revalidation/navigation as part of the same server-driven flow instead of relying on a later client router.push() request that may be intercepted by the browser cache.

So I wouldn't assume updateTag and revalidatePath have fundamentally different cache invalidation semantics here. The important difference seems to be the navigation mechanism and the HTTP caching behavior of the RSC response.

Given that disabling the browser cache or changing the Cache-Control header fixes the issue, that strongly suggests the stale layer is the browser HTTP cache, not the Next.js Data Cache itself.

As a workaround, I would keep revalidatePath('/todolist') + redirect('/todolist') inside the Server Action for now, rather than doing updateTag() and then a client-side router.push().

This issue is caused by the interaction between two completely separate caching layers: the Next.js In-Memory Router Cache and the Browser’s Native HTTP Disk Cache (RFC 9111).

When cacheComponents (use cache) and partialPrefetching (PPR) are enabled in production (next start), Next.js serves prefetchable static shell RSC payloads with HTTP caching headers (such as stale-while-revalidate).

Here is the exact breakdown of what is happening under the hood and why:

1. Why updateTag + client-side router.push fails

1. The Server Action Finishes:
   • updateTag('todolist') successfully purges the tag in the server-side Data Cache.
   • The action returns a success response to the client. Next.js marks the client-side in-memory Router Cache for /todolist as dirty/invalid.
2. router.push('/todolist') is Triggered:
   • Because the in-memory Router Cache is dirty, the Next.js router issues a network fetch for /todolist (with the RSC: 1 header).
3. The Browser Intercepts the Request via Disk Cache:
   • The browser’s HTTP cache sits in front of the network. It has no awareness that a Server Action ran on your backend.
   • Because the previous RSC response for /todolist had HTTP cache headers (produced under PPR prefetching), Chrome finds a match in its disk cache and immediately responds with:

     Status Code: 200 OK (from disk cache)
     

4. Stale Data is Displayed:
   • Next.js receives the stale RSC payload directly from the browser's disk cache, populates the router cache with it, and renders the un-updated list.

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

Their network execution models are fundamentally different:

• With router.push() on the client:

  • The Server Action response is purely a standard Action response.
  • Navigating to /todolist triggers an independent, secondary HTTP GET request from the browser, which gets intercepted and served by Chrome's HTTP Disk Cache.

• With redirect('/todolist') inside the Server Action:

  • In Next.js, calling redirect() inside a Server Action throws a special NEXT_REDIRECT error boundary.
  • Next.js handles this by rendering the destination page (/todolist) directly on the server and streaming the newly rendered RSC payload inside the single Server Action POST response!
  • The browser receives the fresh HTML/RSC payload embedded in the action's response stream alongside the URL transition instruction.
  • Because HTTP POST requests are never cached by the browser's disk cache, and action responses carry Cache-Control: no-store, no-cache, the browser disk cache is completely bypassed. That is why the stale-while-revalidate header disappears.

3. How does the request reach the server after disk cache? (Is it SWR in the browser?)

Yes, exactly.

When an HTTP response has Cache-Control: max-age=0, stale-while-revalidate=..., the browser's native HTTP cache executes Stale-While-Revalidate:

1. It immediately satisfies the soft-navigation request with the stale response from the disk cache so the UI transitions instantly.
2. It asynchronously fires a background conditional request (If-None-Match / If-Modified-Since) to the origin server.
3. Once the server responds, the disk cache updates. On your subsequent navigation or hard refresh, the fresh data finally appears.

The Recommended Solutions

Solution A: Move redirect() into the Server Action (Cleanest)

Let the Server Action handle the redirection. This forces Next.js to stream the fresh destination RSC payload directly in the non-cacheable action response:

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

import { updateTag } from 'next/cache';
import { redirect } from 'next/navigation';

export async function updateTodoItem(id: string, formData: FormData) {
  // 1. Update database
  await db.todo.update({ where: { id }, data: { ... } });

  // 2. Invalidate cache tag
  updateTag('todolist');

  // 3. Redirect on the server (bypasses browser disk cache completely)
  redirect('/todolist');
}

Solution B: Call router.refresh() before router.push() (If you must stay client-side)
If you need client-side control (e.g. displaying toast notifications before navigating), explicitly call router.refresh() to force the client router to issue an un-cached fetch:

// Client-side submit handler
const handleSuccess = async () => {
  await updateTodoAction(formData);
  
  // Forces Next.js to purge router cache and fetch fresh server state
  router.refresh(); 
  router.push('/todolist');
};

I think the key distinction here is between Next.js cache invalidation and the browser's HTTP cache.

updateTag() invalidates the tagged server-side data and Next.js can invalidate the client Router Cache after a Server Action, but that does not necessarily invalidate an already stored HTTP response in the browser's disk cache.

That would explain why the behavior differs between:

• updateTag() followed by a client-side router.push()
• updateTag() / revalidatePath() followed by redirect() from the Server Action

In the first case, the subsequent navigation can issue a separate RSC request, and the browser may satisfy that request from its HTTP cache before it reaches Next.js.

This also matches the observation that disabling the browser cache makes the issue disappear.

I would therefore avoid relying on router.refresh() as a guaranteed workaround here, since the underlying problem appears to be the HTTP caching behavior of the RSC response rather than only the in-memory Router Cache.

For now, using redirect('/todolist') after the mutation/invalidation seems like the safer workaround.

Since this has already been reproduced by the Next.js team, it looks more like a framework/cache-header interaction than an application-level invalidation mistake.

Thanks for bringing this up in RSC payload served from browser disk cache after router cache is cleared by a mutation. I am following this discussion and looking into the details. Happy to help test or contribute to this area!