Partial Prefetching With Custom Cache Miss Returns HTTP 500 On Dynamic Routes

Next.js 16 with partialPrefetching enabled relies on cached prerendered RSC payloads for dynamic routes. With a custom incremental cache that returns null on cold start, the runtime falls back to dynamically rendering the generic fallback shell '/[locale]'. However, during this runtime regeneration, the page is treated as static and any attempt to use uncached data (even though the page only awaits params) triggers NEXT_STATIC_GEN_BAILOUT, causing a 500 error. The underlying design flaw is that the fallback shell for partially prefetched pages is not persisted in the build output when using a custom cache, so the runtime cannot recover without dynamic rendering, which is blocked for static pages.

1. Clone the reproduction repo and npm ci. 2. Build and start the Next.js app with cacheComponents: true, partialPrefetching: true, a custom in-memory incremental cache handler that returns null initially, and cacheMaxMemorySize: 0. 3. Request /en or /fr. Both routes return HTTP 500 with the trace showing a miss for the concrete route and a fallback shell miss, followed by NEXT_STATIC_GEN_BAILOUT.

This workaround introduces file-system I/O on every cache read/write, which may affect performance under high load. It is not suitable for multi-instance deployments unless a shared filesystem (e.g., NFS) is used, and concurrent writes across instances may still cause consistency issues. The cache directory can grow unbounded and may contain sensitive data; ensure proper filesystem permissions and cleanup mechanisms. The revalidateTag implementation is overly broad and will invalidate all cache entries, leading to more frequent regenerations. This is a temporary mitigation; the underlying Next.js bug should be fixed in a future release, after which this custom handler should be removed. To roll back, delete the custom cache handler and restore the default filesystem cache or disable partialPrefetching.