[BUG] ISR with Partial Prerendering fails at runtime on Cloudflare R2

[pbrissaud]

Describe the bug

When deploying a Next.js App Router app using open-next to Cloudflare Workers with R2 object storage as the cache backend, ISR pages using Partial Prerendering (◐) work initially but break after the some times (like 24h ; revalidation period is 1h):

Example of the page :

// app/challenge/[slug].tsx

export const revalidate = 3600;

export async function generateStaticParams() {
  const posts = await getPosts()
  return posts.map((post) => ({ slug: post.slug }));
}

export default async function Page({ params }: { params: { slug: string } }) {
  const awaitedParams = await params;
  const { slug } = awaitedParams as { slug: string }; 
  const post = getPost(slug);

  if (!post) {
    return <h1>404</h1>;
  }

  return (
    <div className="p-8 space-y-4">
      <h1 className="text-3xl font-bold">{post.title}</h1>
      <p>{post.content}</p>

      <Suspense fallback={<p>Loading dynamic content...</p>}>
        <DynamicContent />
      </Suspense>
    </div>
  );
}

The build correctly shows ◐ and the page works at first.

However, after sometimes , the route fails at runtime with:

FatalError: The revalidation for /challenge/[slug] cannot be done. This error should never happen.

After this happens:

• The Suspense fallback spins indefinitely
• Refreshing the page leads to a white screen
• No regeneration ever occurs again

Steps to reproduce

1. Use App Router in Next.js (v14) with open-next

2. Create a route with:

   • Static content loaded
   • A section

3. Deploy with opennextjs-cloudflare build && opennextjs-cloudflare deploy to Cloudflare Workers

4. Visit the page → it works

5. Wait many hours

6. Refresh the page → it fails to revalidate and breaks with the error shown above

Expected behavior

I expect that the route should be revalidated and regenerated after the revalidate interval

@opennextjs/cloudflare version

1.0.2

Wrangler version

4.14.4

next info output

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.4.0: Fri Apr 11 18:33:46 PDT 2025; root:xnu-11417.101.15~117/RELEASE_ARM64_T8112
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 20.15.1
  npm: 10.7.0
  Yarn: 1.22.22
  pnpm: 10.10.0
Relevant Packages:
  next: 15.4.0-canary.30 // There is a newer canary version (15.4.0-canary.31) available, please upgrade! 
  eslint-config-next: 15.4.0-canary.30
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.2.2

Additional context

No response

[vicb]

Please add a minimal repro (link to a GH repository) with instructions on how what you do to see the issue

[joncoronel]

Have the same issue but in a simpler use case. Simply using revalidatePath on a route that uses PPR will break that page on future visits and will render a blank UI.
Repo here: https://github.com/joncoronel/acc2025

Simply click on the "refresh page" button which runs revalidatePath("/") and then manually refresh the page. The page will initially load the UI but then will render a blank page and all future visits will show this blank page.

[grabmateusz]

Hi, our team is affected by this issue as well. This is effectively making ISR not usable for us on OpenNext Cloudflare adapter at all, while our application is heavily depending on this functionality. Is there any ETA for this bug to be worked on?

[Nxmber]

Hi !
With Next 16 and PPR (cacheComponents: true) this issue is even more impactful.
"use cache" with cacheLife (new ISR) works but trigger all dynamic component suspenses indefinitely after the first invalidation time. A page without ISR component (only static or dynamic components) or navigating to the ISR page from another page works, only going straight to this page or refreshing triggers this bug

The log "FatalError: The revalidation for XXXX cannot be done. This error should never happen" is also triggered. (Request ID: XG2NTRMDJFB9ODY5)

Even tho Next 16 is not officially supported i wanted to up this issue now that "use cache" is stable.

Going straight to the page before the first invalidation or navigating to it from another page:

After the invalidation period of ISR components and refreshing the page:

TLDR: ISR components on Next 16 are blocking dynamic components of the same page on inital page load after first invalidation due to cache invalidation error on workers

Thx for the work on this adapter !

[algo7]

Any news on this?

[alex-all3dp]

Hitting this in production on @opennextjs/cloudflare@1.19.9 / Next 16.2.6: ~3.6 FatalError/min on statically-prerendered ISR routes (dynamic = 'error').

Trigger looks like a race: when a user hits a stale page, the in-isolate stale-while-revalidate regenerates it before the DO's queued HEAD self-fetch reaches the ISR handler. Next.js then returns 200 + x-nextjs-cache: HIT instead of REVALIDATED, tripping the strict check at queue.ts:135. Page content is correct; the queue just thinks it didn't do its job.

Opened #1272 with a suggested fix: treat any 200 response as success regardless of x-nextjs-cache, so the sync table is updated and the route is cleared from failed state. Existing test moved + assertion strengthened; full suite + code:checks green.