Middleware runs before route matching, and that ordering is where the entry goes missing. Per the upstream issue, Next matches the pre-rewrite path against its dynamic-route regexes, and `/bot` matches nothing because the real route file is `app/[locale]/[provider]/page.tsx`, so the response falls back to the `private, no-store` default [10]. The author marks that as upstream's account rather than something he can observe from outside the runtime; what he stands behind is that the header pair flips on nothing except whether middleware rewrote the URL [11].
The important property is that this is a write-side failure [12]. No entry is created for those keys, so the absence of any `x-nextjs-*` header on the response is the honest reading: Next never treated the request as a route that has an incremental cache entry [6]. There is also no shape of `NextResponse.rewrite()` that dodges it, and it is neither a matcher nor an ordering problem in your own code [13].
Detection is the hard part, and two mechanics conspire. The bug is per-path, and only paths middleware rewrote are affected, so any "is my ISR working" check aimed at `/ja/...` passes [19]. Then there is the freshness math. `revalidate = 300` is a five-minute window [1], but the buildId changes on every deploy and forms part of the cache key space, and this repo ships several times a day, which dropped the whole cache often enough that no page ever looked stale [8]. Nine prefixed locales plus one unprefixed makes ten locale paths [2], and the broken one was the canonical target that crawlers hit most [2]. The author spent eight minutes polling `/en/bot` before noticing it 307-redirects to `/bot`, so the loop was measuring a redirect [7].
The adapter-side workaround is the part worth reading closely. OpenNext's `enableCacheInterception: true` resolves the cache before NextServer is invoked, which should make pre-rewrite matching irrelevant, and hits did work, with `x-opennext-cache: HIT` on prefixed locales [14]. English stayed broken because those keys were empty [15]. On a stale entry the interceptor has to dispatch the background re-render itself, and no revalidation queue was bound [16]. Inside NextServer that same failure is caught and logged as a warning; in the routing layer nothing caught it, so the request returned 500 [16]. It threw before the render, so the entry could never refresh and the 500 was permanent per URL, and it only fired once an entry passed its revalidate window [17].
For this header pair to transfer to your stack, three things have to hold: App Router, a middleware rewrite landing on a dynamic route, and a version in the affected range, which the issue reports as 15.4.2-canary.2 through 15.5.3 and the author reproduces on 15.5.21 [9]. The measurement itself is one site, dated, on Cloudflare Workers via OpenNext [1][4], so treat it as a reproducible tell rather than a survey. The tell is cheap to run: request the rewritten URL directly, not its prefixed form, and look for `x-nextjs-prerender` rather than parsing the `Cache-Control` string [4][5].
