Next 16.3.0 + OpenNext triggers an unbounded RSC prefetch loop

[ajdiyassin]

Bug

With Next.js 16.3.0 and @opennextjs/cloudflare 1.20.2, an OpenNext preview triggers an unbounded RSC prefetch loop after page load. A fresh build and isolated Chrome profile produced 1,910 Next-Router-Prefetch: 1 requests in 30 seconds (~64 requests/sec), accelerating and repeating the same _rsc payload. This can amplify Workers traffic rapidly.

Control

The same application with Next.js 16.2.12 + OpenNext 1.20.2 produced 0 prefetch requests in 30 seconds. OpenNext 1.20.1 with Next.js 16.3.0 also reproduced the loop, so this is not an OpenNext-version-only regression.

Reproduction: build with next build --turbopack, build/serve with OpenNext Cloudflare, open the app using a fresh browser profile, and observe repeated RSC prefetch requests.

[spira-unplugged]

We hit this in production too, on @opennextjs/cloudflare with next 16.3.1 (not just 16.3.0 — the 16.3.1 "fix" in vercel/next.js#97135 doesn't seem to hold for us; that issue's own repro shows 16.3.1-canary.10 still looping at nearly the same rate as 16.3.0).

Baseline: 30-40k Workers requests/day. After deploying 16.2.6 -> 16.3.1, invocations went to 329M on day 1 and 174M on day 2 before we caught it, almost entirely on a single static page. GA4 shows real user sessions falling over the same window while requests spiked ~75x, and the traffic was ordinary Chrome/Firefox browsers (HTTP/2 + HTTP/3), so this is the prefetch retry loop running in real visitors' tabs, not bots.

One thing not yet in this thread: on Cloudflare specifically the cost blast radius is larger than just Workers requests. @opennextjs/cloudflare's withRegionalCache defaults shouldLazilyUpdateOnCacheHit to true, so every regional cache hit also fires a background R2 GetObject. During the loop our R2 Class B operations tracked Workers requests almost exactly 1:1 (normally ~0.5 reads/request, ~1.0 during the incident). Setting it to false dropped that to 0.01-0.05.

What stopped it for us:

• experimental.optimisticRouting: false (next.config.ts)
• shouldLazilyUpdateOnCacheHit: false (open-next.config.ts)
• prefetch={false} on the one nav link that was absorbing the loop
• a 100 req/10s per-IP rate limit as a backstop

No re-ignition since. Happy to share per-minute Workers/R2 metrics if useful.

[spira-unplugged]

Cross-linking for anyone who lands here from the symptom: the root cause is filed upstream as opennextjs/opennextjs-aws#1212. getBodyForAppRouter gates the segment branch on !NextConfig.experimental?.prefetchInlining, and Next 16.3 makes that value an object ({maxSize, maxBundleSize}), so the branch is dead code and every Next-Router-Segment-Prefetch is answered with the full-page RSC payload and without x-nextjs-postponed. The client never counts the prefetch as satisfied and re-requests indefinitely. #1348 is the Cloudflare-side build-time patch for it.

One addition from my side: the same expression is present in @opennextjs/aws@3.10.2 (pinned by @opennextjs/cloudflare@1.19.2), not only 4.1.0 - so downgrading the adapter does not avoid it.