mirror of
https://github.com/hanzoai/next.js.git
synced 2026-09-24 17:00:51 +00:00
Hendrik LiebauandGitHub
8de4b60049
Applications can now override the `'use cache'` fill timeout through a new `experimental.useCacheTimeout` config (in seconds, matching the `staticPageGenerationTimeout` / `cacheLife` configs), which lets them raise the timeout for slower dev-time backends or lower it for faster feedback while iterating. Without a value set, the timeout defaults to 90% of `staticPageGenerationTimeout`, landing at 54s against the 60s default build timeout — slightly higher than the previous hard-coded 50s. During static and runtime prerendering, the effective timeout is clamped to `0.9 × staticPageGenerationTimeout` so the cache-fill error surfaces before the build worker kills the page. In dev mode, the configured value is used as-is since there's no equivalent build-worker kill. The defaulting and clamp are centralized in a single `getUseCacheFillTimeoutMs` helper in `use-cache-wrapper.ts`, replacing the previous module-level `USE_CACHE_FILL_TIMEOUT_MS` constant. The new value is threaded through `RenderOpts` and `WorkStore`. Proxy/middleware and the edge route-module wrapper construct a WorkStore but never fill `'use cache'` entries, so they pass `0` sentinels with a comment — if anything ever reads these values, the cache will time out immediately and surface the bug loudly. We'll revisit this if we ever add `'use cache'` support to Proxy. A new `use-cache-configured-timeout` fixture exercises the clamp by setting `staticPageGenerationTimeout: 10` and flipping `useCacheTimeout` between `15` (in dev, via `process.env.__NEXT_DEV_SERVER`) and `60` (in build). Two pages, one sleeping 11s (between the 9s clamp and the 15s dev timeout) and one sleeping 17s (above the dev timeout), let us assert that the dev value is applied without clamping and that the build clamps both pages. The existing `use-cache-hanging` fixture now sets `useCacheTimeout: 10` so tests don't race the browser's `page.goto` ceiling, and the explicit 180s test timeouts there have been dropped in favor of the Jest default.
38 lines
1.4 KiB
JavaScript
38 lines
1.4 KiB
JavaScript
/**
|
|
* This configuration is NOT realistic — it's set up to exercise the clamp
|
|
* logic in both dev and build. In practice, users might tune
|
|
* `experimental.useCacheTimeout` up (e.g. for slower dev-time backends) or
|
|
* down (e.g. for faster feedback while iterating); what's unusual here is
|
|
* the very low `staticPageGenerationTimeout`.
|
|
*
|
|
* Setup:
|
|
* - `staticPageGenerationTimeout: 10` → build-time clamp = 9s, with a
|
|
* 1s buffer before the build worker kills the page at 10s.
|
|
* - Dev `useCacheTimeout: 15` → would be clamped to 9s if we clamped in
|
|
* dev. We don't, so the raw 15s applies.
|
|
* - Build `useCacheTimeout: 60` → clamped to 9s.
|
|
* - `/below-dev-timeout` sleeps 11s (between 9s and 15s).
|
|
* - `/above-dev-timeout` sleeps 17s (above 15s).
|
|
*
|
|
* This way:
|
|
* - Dev `/below-dev-timeout` succeeds (proves no clamp; if we clamped, it
|
|
* would time out at 9s < 11s).
|
|
* - Dev `/above-dev-timeout` times out at 15s (proves the configured dev
|
|
* value is actually applied).
|
|
* - Build fails on both pages via the clamp (9s < 11s, 9s < 17s).
|
|
*
|
|
* @type {import('next').NextConfig}
|
|
*/
|
|
const nextConfig = {
|
|
cacheComponents: true,
|
|
staticPageGenerationTimeout: 10,
|
|
experimental: {
|
|
useCacheTimeout: process.env.__NEXT_DEV_SERVER ? 15 : 60,
|
|
// Keep building all pages after a failure so the test can assert that
|
|
// both pages timed out via the clamp.
|
|
prerenderEarlyExit: false,
|
|
},
|
|
}
|
|
|
|
module.exports = nextConfig
|