mirror of
https://github.com/hanzoai/next.js.git
synced 2026-09-24 17:00:51 +00:00
Hendrik LiebauandGitHub
286862e35b
In development, editing a file does not evict existing `'use cache'` entries; an entry is invalidated only by re-keying, and the key includes an HMR refresh hash. That hash was delivered through the `__next_hmr_refresh_hash__` cookie, which the browser HMR client set from each server-components change and sent back on later requests. Two cases were therefore broken. First, any request that does not carry the cookie (a `curl`, a plain `fetch`, a fresh browser profile, a second device) served stale cached content after an edit, for both pages and route handlers. Second, on Turbopack a route handler served stale content even when fetched from a page whose HMR client had the cookie, because a route-handler edit never advanced the hash there and so never updated the cookie; on webpack that case happens to work, leaving only cookieless route handlers broken. The hash is server-authored to begin with (webpack's `stats.hash`, Turbopack's `hmrHash` counter), so this change sources it directly on the server and removes the cookie entirely. The hot-reloader exposes it, and `base-server` attaches it to each request with `addRequestMeta`, next to `serverComponentsHmrCache`, so it reaches every render, including the internal Cache Components validation and warmup renders. It is threaded onto the request store the same way `serverComponentsHmrCache` is, so `'use cache'` is invalidated for every client regardless of whether it ran the HMR client. Route handlers, whose `NextRequest` does not carry request meta, receive it through the app-route template's `renderOpts`. Editing a route handler also has to advance the hash in the first place. On webpack it already did, but on Turbopack the `app-route` entry wired no change subscription, so a route edit recompiled the module without advancing `hmrHash`; it now subscribes to the route endpoint so an edit advances the hash without broadcasting a page refresh. That subscription is also made the only thing that advances `hmrHash`: the config-invalidation and server Fast Refresh reset paths previously bumped it even without a content change, for example on a route's first load, and with the hash now read synchronously instead of bounced back through a cookie, such a bump would land between a route's cold write and warm read and evict a still-valid entry. The getter returns the counter unconditionally so the key is present and stable for every request, matching webpack's always-present `stats.hash`. With the cookie gone, the `hash` field on the `SERVER_COMPONENT_CHANGES` HMR message has no remaining consumer, so it is dropped from the message type and both bundlers. This is a short-term stopgap until the granular implementation hash (`codeHash` plus `runtimeEnvVars` plus the Next.js version) is used in `next dev`, which invalidates server-authoritatively by construction and will let this mechanism be removed. > [!TIP] > Best reviewed with hidden whitespace changes. closes NAR-894 --- <sub>Stack created with <a href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
67 lines
2.5 KiB
TypeScript
67 lines
2.5 KiB
TypeScript
import { nextTestSetup } from 'e2e-utils'
|
|
import { retry } from 'next-test-utils'
|
|
|
|
describe('use-cache-default-handler-expire-zero', () => {
|
|
const { next, skipped, isNextStart } = nextTestSetup({
|
|
files: __dirname,
|
|
// Enable the built-in default cache handler's debug logging so we can
|
|
// assert on its `set()` decisions in the CLI output. That output is not
|
|
// available on deploy, so skip the deploy variant.
|
|
env: { NEXT_PRIVATE_DEBUG_CACHE: '1' },
|
|
skipDeployment: true,
|
|
})
|
|
|
|
if (skipped) {
|
|
return
|
|
}
|
|
|
|
if (isNextStart) {
|
|
it('does not save an expire:0 cache to the built-in default handler, but saves a short-lived one', async () => {
|
|
const browser = await next.browser('/')
|
|
expect(
|
|
await browser.elementById('expire-zero-value').text()
|
|
).toBeDateString()
|
|
expect(
|
|
await browser.elementById('short-lived-value').text()
|
|
).toBeDateString()
|
|
|
|
// The default handler skips storing the `expire: 0` entry (it would never
|
|
// be served back in production)...
|
|
expect(next.cliOutput).toMatch(
|
|
/DefaultCacheHandler: set \["[A-Za-z0-9_-]+","([0-9a-f]{2})+",\[{"id":"expire-zero"}]\] skipped dynamic entry/
|
|
)
|
|
|
|
// ...and never reports it as stored.
|
|
expect(next.cliOutput).not.toMatch(
|
|
/DefaultCacheHandler: set \["[A-Za-z0-9_-]+","([0-9a-f]{2})+",\[{"id":"expire-zero"}]\] done/
|
|
)
|
|
|
|
// The short-lived (`expire: 60`) cache is still stored.
|
|
expect(next.cliOutput).toMatch(
|
|
/DefaultCacheHandler: set \["[A-Za-z0-9_-]+","([0-9a-f]{2})+",\[{"id":"short-lived"}]\] done/
|
|
)
|
|
})
|
|
} else {
|
|
it('saves an expire:0 cache to the built-in default handler in dev', async () => {
|
|
const browser = await next.browser('/')
|
|
expect(
|
|
await browser.elementById('expire-zero-value').text()
|
|
).toBeDateString()
|
|
|
|
// In development the default handler keeps `expire: 0` entries (its
|
|
// minimum retention serves them warm across reloads), so it stores rather
|
|
// than skips. The dev cache key always carries a trailing HMR refresh
|
|
// hash element after the args array.
|
|
await retry(async () => {
|
|
expect(next.cliOutput).toMatch(
|
|
/DefaultCacheHandler: set \["[A-Za-z0-9_-]+","([0-9a-f]{2})+",\[{"id":"expire-zero"}],"[^"]+"\] done/
|
|
)
|
|
})
|
|
|
|
expect(next.cliOutput).not.toMatch(
|
|
/DefaultCacheHandler: set \["[A-Za-z0-9_-]+","([0-9a-f]{2})+",\[{"id":"expire-zero"}],"[^"]+"\] skipped/
|
|
)
|
|
})
|
|
}
|
|
})
|