[BUG] `enableCacheInterception` never serves segment prefetches on Next 16, causing an unbounded prefetch loop

[midildar]

[BUG] enableCacheInterception never serves segment prefetches on Next 16, causing an unbounded prefetch loop

Summary

On Next 16, the cache interceptor's segment-response branch is unreachable. Every
Next-Router-Segment-Prefetch request is answered with the full-page RSC
payload and full-page headers, even when the requested segment is present in
the cache entry.

The client router never receives the segment it asked for, never records the
prefetch as satisfied, and re-requests indefinitely. An idle App Router landing
page with four <Link>s in view produced ~780 requests in two minutes and
did not stop.

The trigger is a truthiness check: the branch is gated on
!NextConfig.experimental?.prefetchInlining, which reads as though written when
that setting was a boolean. Next 16 defaults it to an object, so the negation
is always false.

This affects every Next 16 app running enableCacheInterception: true — no
experimental configuration is required to hit it.

Environment

@opennextjs/aws	4.1.0 (latest)
@opennextjs/cloudflare	1.20.2 (latest)
next	16.3.0 (latest)
wrangler	4.114.0
Runtime	opennextjs-cloudflare preview (workerd, local)

App shape: App Router, no middleware, ppr: false, clientSegmentCache
unset, no experimental block in next.config.ts at all. Three SSG routes
via generateStaticParams with export const revalidate = 300, plus a static
index that links to them.

// open-next.config.ts
export default defineCloudflareConfig({
  incrementalCache: withRegionalCache(r2IncrementalCache, { mode: 'long-lived' }),
  enableCacheInterception: true,
});

Reproduction

1. Build and run opennextjs-cloudflare preview --env production.
2. Open a page containing <Link>s to prerendered routes.
3. Leave the tab idle and watch the network panel or the wrangler request log.

Evidence

1. A/B on identical code, only the flag differing

enableCacheInterception	Requests after load + 30s idle
true	hundreds, repeating one _rsc hash, never settles
false	33, then silence

Not a Next-only bug: next start on the same build does not loop. (It does
duplicate prefetches 2–3×, which looks like
vercel/next.js#85489 — the
interceptor turns that bounded duplication into something unbounded.)

2. Segment prefetch is answered with the full page

curl -D - "http://localhost:8787/category/cpu?_rsc=probe" \
  -H "RSC: 1" -H "Next-Router-Prefetch: 1" \
  -H "Next-Router-Segment-Prefetch: /_tree"

enableCacheInterception: true — plain and segment prefetch return
byte-identical bodies (12864 bytes) and identical headers:

content-type: text/x-component
x-nextjs-prerender: 1
x-nextjs-stale-time: 300
x-opennext-cache: HIT

enableCacheInterception: false (NextServer handling it) — the two diverge,
as expected:

plain prefetch    -> x-nextjs-prerender: 1,1   x-nextjs-stale-time: 300
segment prefetch  -> x-nextjs-prerender: 1     x-nextjs-postponed: 2   (no stale-time)

3. The segment is in the cache — it just isn't served

.open-next/cache/<buildId>/category/cpu.cache:

full rsc                                        12857 bytes
segment /_tree                                    959 bytes
segment /_full                                  12857 bytes
segment /category/$d$handle/__PAGE__            10852 bytes
segment /category/$d$handle/@modal/__DEFAULT__    307 bytes

segmentHeader in cachedValue.segmentData is true for /_tree, and a
959-byte payload is available. The interceptor returns the 12857-byte full page
regardless.

Root cause

packages/open-next/src/core/routing/cacheInterceptor.ts, in
getBodyForAppRouter:

const segmentHeader = `${event.headers[NEXT_SEGMENT_PREFETCH_HEADER]}`;
const isSegmentResponse =
  Boolean(segmentHeader) &&
  segmentHeader in (cachedValue.segmentData || {}) &&
  !NextConfig.experimental?.prefetchInlining;   // <-- always false on Next 16

const body = isSegmentResponse ? cachedValue.segmentData[segmentHeader] : cachedValue.rsc;

On Next 16.3.0, with no experimental block configured,
.next/required-server-files.json contains:

"prefetchInlining": { "maxSize": 2048, "maxBundleSize": 10240 }

An object is truthy, so !NextConfig.experimental?.prefetchInlining evaluates to
false and isSegmentResponse can never be true. The segment branch is dead
code on Next 16.

Because additionalHeaders is only populated on that branch, the response also
omits x-nextjs-postponed, so the client can't even tell it received something
other than what it asked for.

Suggested fix

The check appears to predate prefetchInlining becoming an object. Two
directions, depending on the original intent of gating segment responses on
inlining at all:

1. Test the setting in a shape-aware way rather than by truthiness.
2. Drop it and rely on the segmentData membership test that already precedes it.

Independently, a safety net would help: when Next-Router-Segment-Prefetch is
present and the segment can't be served as a segment, returning event and
letting NextServer handle it would avoid answering with a different response
shape than the client requested. That matches the interceptor's documented
contract that it "should fallback to the NextServer if the cache is not found".

Minor, adjacent

const segmentHeader = `${event.headers[NEXT_SEGMENT_PREFETCH_HEADER]}`;

A missing header stringifies to the literal "undefined", so
Boolean(segmentHeader) is always true. Harmless today, since
"undefined" in segmentData is false, but the guard doesn't do what it looks
like it does.

Docs note

enableCacheInterception is in DangerousOptions and defaults to false, so
this is opt-in — but the only documented incompatibility is PPR, and nothing
mentions RSC or segment prefetching. Given Next 16's segment prefetching, the
practical cost of enabling it is now considerably worse than "slightly improve
cold start performance". A documentation warning would help even if the code fix
doesn't land.

---

Happy to put together a minimal reproduction repo if that would help.

[bevdam]

Adding a second, independent route to the same symptom in case it helps triage — this one isn't enableCacheInterception, which we have off at its default.

On sst.aws.Nextjs (SST 4.17.1, Next 16.3.0) the CloudFront cache key omits next-router-segment-prefetch. SST hashes a fixed header list into x-open-next-cache-key:

var headers = ["rsc","next-router-prefetch","next-router-state-tree","next-url","x-prerender-revalidate"];

so a /_tree segment request and a full-page request produce the same key, and CloudFront answers the segment request with the cached full-page payload — the same end state you describe, reached at the CDN rather than in the interceptor. Two requests differing only in Next-Router-Segment-Prefetch returned byte-identical 6532-byte bodies on our deployment; 63–180 req/s per open tab, indefinitely.

Why it goes unbounded rather than merely wasteful may be worth noting for both cases: for a build-time prerendered route the full-page payload carries PrefetchHint.InliningHintsStale, and the client's recovery for that flag is precisely to re-fetch the corrected tree. If the segment request can't return the tree, the flag can never clear.

What makes this easy to fall into: Next's CDN caching guide lists next-router-segment-prefetch under "What you can safely ignore" — "the server falls back to a broader prefetch payload instead of a segment-specific one." True and harmless for dynamic routes; not for prerendered ones.

Filed on the SST side as anomalyco/sst#6969.

(AI-assisted investigation; measurements taken against a live deployment and verified against installed sources.)

[spira-unplugged]

Corroborating this from a different version and at production scale.

The same gate is in @opennextjs/aws@3.10.2, not only 4.1.0

Your report and the Cloudflare-side patch (opennextjs/opennextjs-cloudflare#1348) both describe this as a 4.1.0 problem. I run @opennextjs/cloudflare@1.19.2, which pins @opennextjs/aws@3.10.2, and getBodyForAppRouter there is identical:

// node_modules/@opennextjs/aws/dist/core/routing/cacheInterceptor.js
const segmentHeader = `${event.headers[NEXT_SEGMENT_PREFETCH_HEADER]}`;
const isSegmentResponse = Boolean(segmentHeader) &&
    segmentHeader in (cachedValue.segmentData || {}) &&
    !NextConfig.experimental?.prefetchInlining;

.next/required-server-files.json from my next 16.3.1 build has the shape you found: "prefetchInlining": {"maxSize":2048,"maxBundleSize":10240}. So the dead branch predates 4.1.0, and whichever fix lands is worth describing as covering the older line too - otherwise people on 1.19.x / 3.10.x will read the existing reports and assume they are unaffected.

The type declaration still says boolean

You noted the check "reads as though written when that setting was a boolean". It is still declared that way:

// dist/types/next-types.d.ts
export interface NextConfig {
    ...
    experimental: {
        ...
        prefetchInlining?: boolean;
    };
}

while Next reads prefetchInlining.maxSize / .maxBundleSize and coerces with Boolean(...) where it wants a flag (next/dist/server/app-render/app-render.js). Whichever of your two suggested directions is taken, widening that type to boolean | { maxSize: number; maxBundleSize: number } seems worth including in the same change - otherwise the next !config.experimental.x check can go dead in exactly the same silent way.

Production impact, since this is filed as opt-in

Small site on Cloudflare Workers, normally 30-40k requests/day. Deploying next 16.2.6 -> 16.3.1 with enableCacheInterception: true produced 329M Workers requests on day one and 175M on day two before I caught it - about 504M requests and 503M R2 Class B reads in 32 hours, from real browsers (HTTP/2 and HTTP/3, ordinary consumer IPs, 15-25 req/s per tab), on a $5/month plan. Analytics for human sessions moved the opposite way across the same days, so it was not load.

Setting experimental.optimisticRouting: false in next.config.ts stopped it; I still run enableCacheInterception: true. Mentioning the scale only because "opt-in and off by default" makes this easy to file as low priority: when it does fire, it fires against a metered runtime with no upper bound and no signal until the invoice moves.

Happy to supply per-minute data or test a candidate fix.