mirror of
https://github.com/hanzoai/next.js.git
synced 2026-09-24 17:00:51 +00:00
To make `cacheMaxMemorySize: 0` fast in development, the `'use cache'` wrapper forced every built-in cache entry to a dynamic cache life (`revalidate: 0`, a five-minute `expire`) so that warm reads would serve the stale value and regenerate a fresh one in the background. That forcing leaked into the stored entry, and an entry with `revalidate: 0` is treated as too dynamic to live in a static shell. On a warm reload of a route that is fully cached and has no `<Suspense>` above the `'use cache'`, the dev validation prerender read the entry and threw an error claiming that a `'use cache'` with zero `revalidate` was nested inside another `'use cache'` that has no explicit `cacheLife`, even though nothing was actually nested, and reported the route as a blocking route. The cold load was unaffected because the entry did not exist yet. With this change the size-0 case no longer forces a dynamic cache life and keeps the entry's resolved life instead: the explicit `cacheLife()` values when the user set them, otherwise the default (a 15-minute `revalidate` and an infinite `expire`). That default sits well above the dynamic thresholds, so a fully cached route can be prerendered again and the false-positive blocking error is gone. An explicitly short `cacheLife()` still makes the route legitimately dynamic without a spurious throw, because the explicit-revalidate and explicit-expire flags are then set. Private caches are unchanged and remain forced-dynamic. So that reloads keep showing a fresh value now that the stored life is no longer always stale, the background revalidation in the cache-hit path also fires for size-0 built-in entries regardless of the stored `revalidate`, restricted to the dynamic dev request render so the dev validation prerender does not also regenerate.
6 lines
86 B
TypeScript
6 lines
86 B
TypeScript
export default async function Home() {
|
|
'use cache'
|
|
|
|
return <p>Hello, world!</p>
|
|
}
|