[BUG] Next.js 16.2.3 / opennextjs-cloudflare 1.19.0 - revalidateTag with profile "max" / stale-while-revalidate does not work

[grabmateusz]

Describe the bug

Currently OpenNext Cloudflare Adapter does not support revalidateTag with profile "max" / stale-while-revalidate.
After recent changes execution of:

revalidateTag('', 'max')

does not affect instance at all, silently, without any form of log that would allow to track down the issue. Request to revalidation endpoint returns 200, revalidateTag('<tag>', 'max') is executed, but ISRed route still returns "HIT"

Issue was originally created as #1058 but was prematurely closed.

This functionality is confirmed to work this way on both self-hosted Next.js application and Next.js application hosted on Vercel.

Steps to reproduce

Checkout branch next-16-d1-next-tag-cache-solution-opennextjs-cloudflare-1-19-0 from reproduction repository
Try to build and deploy code as per README
Visit https:///isr to render ISRed page
Call https:///api/revalidate-data-cache to revalidate data cache using revalidateTag method
Visit https:///isr to render ISRed page

Expected behavior

Like on self-hosted Next.js application or in application deployed to Vercel - second visit to https:///isr should return markup immediately with STALE cache and should revalidate given path in the background, so subsequent requests will have up-to-date cache once it's revalidated.

@opennextjs/cloudflare version

1.19.0

Wrangler version

4.81.1

next info output

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:15 PST 2026; root:xnu-12377.81.4~5/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 22.21.1
  npm: 10.9.4
  Yarn: 1.22.21
  pnpm: N/A
Relevant Packages:
  next: 16.2.3 // Latest available version is detected (16.2.3).
  eslint-config-next: 15.4.6
  react: 19.1.4
  react-dom: 19.1.4
  typescript: 5.9.3
Next.js Config:
  output: N/A

Additional context

No response

[vicb]

Could you please try with the regional cache withRegionalCache(...).
Thanks

[conico974]

Could you try without enableCacheInterception ? I'll try to take some time to look at it this week-end

[grabmateusz]

@vicb You've written:

Could you please try with the regional cache withRegionalCache(...). Thanks

The reproduction repository branch which I've provided in the ticket contains such an open-next.config.ts file:

import { defineCloudflareConfig } from "@opennextjs/cloudflare";
import r2IncrementalCache from "@opennextjs/cloudflare/overrides/incremental-cache/r2-incremental-cache";
import { withRegionalCache } from "@opennextjs/cloudflare/overrides/incremental-cache/regional-cache";
import d1NextTagCache from "@opennextjs/cloudflare/overrides/tag-cache/d1-next-tag-cache";
import doQueue from "@opennextjs/cloudflare/overrides/queue/do-queue";
 
export default defineCloudflareConfig({
  incrementalCache: withRegionalCache(r2IncrementalCache, {
    mode: "long-lived",
    shouldLazilyUpdateOnCacheHit: true,
  }),
  queue: doQueue,
  tagCache: d1NextTagCache,
  enableCacheInterception: true,
});

So as you can see it was already configured.

@conico974 You've written:

Could you try without enableCacheInterception ? I'll try to take some time to look at it this week-end

When I've applied such a change to reproduction repository I see results I would expect. However on real life project after applying this fix I have:

• much slower response for html markup (result of lack of enableCacheInterception: true), like from 200-500 ms to 1-3 seconds,
• undeterministic (from my perspective) behaviour of cache, because for same route where I have 5 minutes cache I receive in few seconds x-nextjs-cache response headers with values:
  STALE -> STALE -> HIT -> STALE -> STALE

So this is not resolving the problem, on real life project it makes situation even worse.

[vicb]

Sorry I meant w/o.

But it looks like Nico was spot on 🙏

[conico974]

@grabmateusz Could you check with this #1193 (comment)

Also could you share your open-next.config.ts, it's hard to diagnose anything without it

[grabmateusz]

@grabmateusz Could you check with this #1193 (comment)

Also could you share your open-next.config.ts, it's hard to diagnose anything without it

Hi @conico974, we're using the one mentioned in my last comment twice, once via link, once with the exact content.

[conico974]

I was talking about your real life project, you use the same config there?

[grabmateusz]

I was talking about your real life project, you use the same config there?

Yes, config is the same.
In the meantime I test your PR package, will let you know once I have any findings.

[grabmateusz]

Tested on real life project with shared by you package, build reports:

Next.js version : 16.2.3
@opennextjs/cloudflare version: 1.19.1
@opennextjs/aws version: https://pkg.pr.new/@opennextjs/aws@1142

open-next.config.ts:

import { defineCloudflareConfig } from "@opennextjs/cloudflare";
import r2IncrementalCache from "@opennextjs/cloudflare/overrides/incremental-cache/r2-incremental-cache";
import { withRegionalCache } from "@opennextjs/cloudflare/overrides/incremental-cache/regional-cache";
import doQueue from "@opennextjs/cloudflare/overrides/queue/do-queue";
import d1NextTagCache from "@opennextjs/cloudflare/overrides/tag-cache/d1-next-tag-cache";

export default defineCloudflareConfig({
  incrementalCache: withRegionalCache(r2IncrementalCache, {
    mode: "long-lived",
    shouldLazilyUpdateOnCacheHit: true,
  }),
  queue: doQueue,
  tagCache: d1NextTagCache,
  enableCacheInterception: true,
});

When I call:

revalidateTag('<tag>', 'max')

Nothing happens, I still see Header:

x-opennext-cache: HIT.

Regardless of calling:

revalidateTag('<tag>', 'max')

[conico974]

Could you remove shouldLazilyUpdateOnCacheHit, this likely mess with the system as it may create a race condition.
Is it the same on the repro? Haven't had the time to test it yet