Cache interception fetches the same key twice on a miss

[km-tr]

Describe the bug

When enableCacheInterception is enabled, an ISR cache miss causes the incremental cache to be queried twice for the same key within a single request.

cacheInterceptor fetches the entry, and on a miss it returns the event without passing the (empty) result downstream. NextServer then starts and the cache handler fetches the very same key again:

• cacheInterceptor.ts — const cachedData = await globalThis.incrementalCache.get(cacheKey), then if (!cachedData?.value) return event
• adapters/cache.ts — const cachedEntry = await globalThis.incrementalCache.get(key, "cache")

None of the four return event paths carry the fetched result, so the second lookup is unavoidable.

On a hit this costs nothing, but on a miss the store round-trip is paid twice before any rendering starts.

Observed impact

Running on Cloudflare Workers with the R2 incremental cache, using Workers automatic tracing. Every ISR miss shows two cache_match / r2_get pairs before the API fetches begin:

cache_match (regional cache)      4 ms
r2_get                          288 ms   <- cacheInterceptor
cache_match (regional cache)      3 ms
r2_get                          306 ms   <- NextServer cache handler
fetch (API, parallel)           212 ms
r2_put                        1,633 ms

Five consecutive traces of different pages all showed exactly two r2_get spans, 274–319 ms each. That is roughly 290 ms of avoidable latency per miss, about 20–25 % of the total request time in our case.

Sites where most requests hit the cache will not notice this. Sites with a long tail of rarely-visited pages (ours has one page per restaurant) miss often, so the duplicate lookup is paid on a large share of requests.

Steps to reproduce

1. Deploy an app with enableCacheInterception: true and an incremental cache backed by remote storage
2. Request an ISR page whose entry is not in the cache
3. Observe two lookups for the same key — via tracing, or by logging inside the incremental cache override's get

Expected behavior

The key should be fetched once per request. Some options:

• Pass the interceptor's result (including the miss) to the downstream cache handler
• Memoize incrementalCache.get for the duration of a request

Request-scoped memoization would not have the correctness problem discussed in #621, since it cannot outlive a single request and therefore cannot serve data invalidated by on-demand revalidation.

Versions

• @opennextjs/aws: 4.0.2 (behaviour confirmed unchanged on main)
• @opennextjs/cloudflare: 1.20.1
• Next.js: 15
• Deployed on Cloudflare Workers

I have not measured this on AWS/S3, but the code path is shared.

[km-tr]

We hit this in production and worked around it on our side. Sharing the numbers and the workaround in case it's useful.

Impact we measured

Sampling 40 real page requests from Workers traces (Cloudflare, R2 incremental cache + withRegionalCache):

	count
regional cache hit (no r2_get)	8
R2 hit (1 r2_get)	26
full miss (2 r2_get)	6

So 19% of misses read the same object twice. We confirmed both reads use an identical R2 key by comparing cloudflare.r2.request.key on the two spans.

Both reads happen before rendering and are serial, so on our setup each one adds ~280ms to TTFB. It is most visible right after a deploy, when the build ID changes and every request is a full miss.

Workaround

Rather than patching, we memoized reads per request in a thin wrapper around the incrementalCache override:

import { getCloudflareContext } from '@opennextjs/cloudflare'

type Memo = Map<string, Promise<unknown>>

// NOTE: must live on globalThis, not module scope — see below
const MEMOS = Symbol.for('incremental-cache-reads')

function getMemoStore(): WeakMap<object, Memo> {
  const g = globalThis as { [MEMOS]?: WeakMap<object, Memo> }
  return (g[MEMOS] ??= new WeakMap())
}

function getRequestMemo(): Memo | null {
  let context: object
  try {
    context = getCloudflareContext()
  } catch {
    return null // next dev / vitest run outside workerd
  }
  const store = getMemoStore()
  const existing = store.get(context)
  if (existing !== undefined) return existing
  const memo: Memo = new Map()
  store.set(context, memo)
  return memo
}

const memoKeyOf = (key: string, cacheType?: string) => `${cacheType ?? 'cache'}:${key}`

export function withDedupedReads(cache) {
  return {
    name: cache.name,

    get(key, cacheType) {
      const memo = getRequestMemo()
      if (memo === null) return cache.get(key, cacheType)

      const memoKey = memoKeyOf(key, cacheType)
      const memoized = memo.get(memoKey)
      if (memoized !== undefined) return memoized

      const pending = cache.get(key, cacheType)
      memo.set(memoKey, pending)
      // don't keep a rejected read around, or every later read in the same
      // request inherits the same failure
      pending.catch(() => {
        if (memo.get(memoKey) === pending) memo.delete(memoKey)
      })
      return pending
    },

    set(key, value, cacheType) {
      getRequestMemo()?.delete(memoKeyOf(key, cacheType))
      return cache.set(key, value, cacheType)
    },

    delete(key) {
      getRequestMemo()?.delete(memoKeyOf(key))
      return cache.delete(key)
    },
  }
}

The key is the per-request object returned by getCloudflareContext(), which is what AsyncLocalStorage holds for the request, so entries do not leak across requests.

Result in production, comparing the ~20 minutes right after a deploy (cold cache, so almost everything is a full miss):

	GetObject	PutObject	Get/Put
before	4,386	2,306	1.90
after	1,855	1,865	0.99

Note for overrides that need request-scoped state

globalThis.incrementalCache is constructed independently in each bundle:

• adapters/middleware.js
• core/createMainHandler.js

The override module is therefore evaluated once per bundle, and module-scoped state is not shared between them. cacheInterceptor runs on the middleware side while adapters/cache runs on the server side, so a memo held in module scope never dedupes these two reads. It has to live on globalThis.

This is also invisible to unit tests, since a single module instance always shares its own scope. Verifying it requires measuring actual storage operations on a deployed build.