How to Fix: Ensure the component tree is only rendered once during SSG/revalidations #67680. Why hasn’t it been merged in the release?

Static generation revalidation can accidentally render the same React component tree more than once, which means duplicated data fetching, higher server load, and inconsistent cache behavior during SSG and ISR. That is the core problem discussed in the linked Next.js pull request, and it explains why users noticed extra requests whenever a page was regenerated.

Understanding the Root Cause

The issue comes from the way Next.js handles server-side rendering pipelines for static output and later revalidation. During an ISR refresh, the framework may need to:

• prepare metadata for the route,
• resolve async server component boundaries,
• collect cacheable fetch results, and
• produce the final HTML and RSC payload.

If those stages are not coordinated around a single shared render pass, the application tree can be evaluated multiple times. In practice, that means code like database queries, CMS fetches, analytics side effects, or expensive transformations may run twice or more during one regeneration cycle.

This is especially visible in the App Router because Server Components can trigger async work during render. If the render pipeline first walks the tree to discover data dependencies and then renders again to emit output, any non-deduplicated fetch or side effect may execute repeatedly.

That behavior causes several real-world problems:

• Duplicate outbound requests to APIs and databases.
• Longer regeneration times because the same component subtree is recomputed.
• Higher infrastructure cost under traffic spikes.
• Unexpected side effects when render logic is not idempotent.

The linked PR aims to ensure the component tree is rendered once during static generation and revalidation, rather than allowing separate internal phases to trigger repeated renders.

Step-by-Step Solution

If you are affected today, there are two parts to the solution: first, reduce the damage in your app code; second, track the framework-level fix and validate it when available in a stable or canary release.

1. Confirm that the tree is rendering multiple times

Add temporary server-side logging around the expensive code path:

export default async function Page() {
  console.log('Rendering page at', new Date().toISOString())

  const data = await getData()

  return <main>{data.title}</main>
}

If revalidation causes duplicate logs for one regeneration event, you are likely hitting this behavior.

2. Make data access idempotent and cache-aware

Move external requests into a dedicated function and use the built-in caching model consistently:

async function getData() {
  const res = await fetch('https://api.example.com/page-data', {
    next: { revalidate: 60 },
  })

  if (!res.ok) {
    throw new Error('Failed to fetch page data')
  }

  return res.json()
}

export default async function Page() {
  const data = await getData()
  return <main>{data.title}</main>
}

This does not fully fix duplicate render passes inside the framework, but it helps avoid repeated network calls when fetch deduplication applies correctly.

3. Avoid side effects during render

Do not write audit logs, mutate records, enqueue jobs, or increment counters directly in the render path:

export default async function Page() {
  // Avoid doing this in render
  // await db.pageViews.increment({ slug: 'home' })

  const data = await getData()
  return <main>{data.title}</main>
}

Instead, move side effects into:

• route handlers,
• server actions where appropriate,
• post-render background jobs, or
• client-triggered analytics.

4. Use React cache helpers for expensive shared computations

If your render tree computes the same server-side result in multiple places, wrap it with a cache boundary:

import { cache } from 'react'

const getProduct = cache(async (id) => {
  const res = await fetch(`https://api.example.com/products/${id}`, {
    next: { revalidate: 300 },
  })

  if (!res.ok) throw new Error('Failed to fetch product')
  return res.json()
})

export default async function Page({ params }) {
  const product = await getProduct(params.id)
  return <main>{product.name}</main>
}

This reduces repeated work even if separate branches of the same request try to resolve identical data.

5. Test against a canary release when the patch is available

Because the root issue is in Next.js internals, the actual fix depends on framework changes. When a canary includes the patch, upgrade in a branch and compare render counts.

npm install next@canary react@latest react-dom@latest

Then run a production build and validate revalidation behavior:

npm run build
npm run start

Trigger revalidation, inspect logs, and confirm that one regeneration leads to one render of the page tree.

6. Watch the PR and release notes

The correct source of truth is the pull request and release changelog. Monitor the PR discussion and the Next.js releases page to see whether the change lands in canary first, is revised, or is deferred.

Common Edge Cases

• Non-fetch data libraries: built-in request deduplication mainly helps native fetch. If you use Prisma, Supabase SDK calls, GraphQL clients, or custom HTTP libraries, duplicate render passes can still trigger repeated operations unless you add your own memoization.
• Dynamic route params: pages with many static params may hide the problem during build but expose it under ISR when individual paths revalidate under live traffic.
• Mixed static and dynamic segments: if a route contains dynamic server logic, partial caching assumptions may break, making duplicate execution harder to diagnose.
• Side effects in shared layouts: even if the page itself looks correct, duplicated rendering in a parent layout can trigger extra requests for navigation, user context, or theme configuration.
• Streaming boundaries: Suspense and streamed server component payloads can make duplicate work appear intermittent because different branches resolve at different times.

Why It Hasn’t Been Merged in a Release

If you are asking why the fix has not shown up in a release yet, the short answer is that framework-level rendering changes are high risk. A patch like this touches core behavior in:

• render orchestration,
• cache collection,
• RSC payload generation, and
• ISR correctness.

Even when a pull request looks straightforward, the Next.js team may delay merging or releasing it for several reasons:

• the fix could break another rendering path,
• it may require additional regression coverage,
• it might only be safe after related internal refactors,
• it may behave differently across Node and Edge runtimes, or
• it may need validation against large internal test matrices before entering stable.

So the absence from a release does not automatically mean the issue was ignored. More often, it means the team is treating it as a core renderer stability change rather than a small bugfix.

For production teams, the practical takeaway is simple: assume the framework fix is pending until it appears in an official release note, and use defensive patterns now to avoid duplicated work during revalidation.

FAQ

Does this bug affect only ISR, or also the initial static build?

It can affect both static generation and revalidation, depending on the route and render path. Many users notice it most during ISR because the duplicate requests become visible under production traffic.

Will fetch deduplication fully solve the problem?

No. Fetch deduplication helps with repeated identical native fetch calls, but it does not protect every type of async work. Database queries, custom clients, and side effects can still run multiple times if the tree is rendered more than once.

How should I safely code around this until the framework fix ships?

Keep render logic pure, cache expensive server computations, use native fetch with proper revalidate settings when possible, and move mutations or analytics out of the render path. That minimizes risk even before the upstream patch is released.