Upstream change
Next.js commit 07f76411b07de9417d4a6b816f3137cafe1045fc changes the cache key seed used by "use cache" (via cacheHandlers) to include deploymentId, falling back to buildId when deploymentId is unset.
Relevant change in packages/next/src/server/use-cache/use-cache-wrapper.ts:
- const buildId = workStore.buildId
+ const buildId = workStore.deploymentId || workStore.buildId
The PR description notes this was previously broken in dev, where buildId = "development" meant the same cache key was used across deployments. deploymentId is now threaded through the build pipeline, work store, and AppRouteSharedContext.
Test fixture: test/production/app-dir/use-cache-cross-deployment/ (asserts that changing NEXT_DEPLOYMENT_ID or BUILD_ID produces different cache keys, including across the default cache handler).
Why this matters for vinext
vinext implements "use cache" and ships a KV-based CacheHandler for Cloudflare Workers. To match Next.js parity:
"use cache" cache keys must incorporate the deployment identifier so that different deployments do not share cached results.- On Cloudflare Workers, the natural mapping is the Workers version ID /
CF_VERSION_METADATA (or a build-time environment variable equivalent to NEXT_DEPLOYMENT_ID).
- The fallback to
buildId should be preserved, and the existing buildId = "development" problem should be considered for vinext dev mode as well.
Action items
References
Upstream change
Next.js commit 07f76411b07de9417d4a6b816f3137cafe1045fc changes the cache key seed used by
"use cache"(viacacheHandlers) to includedeploymentId, falling back tobuildIdwhendeploymentIdis unset.Relevant change in
packages/next/src/server/use-cache/use-cache-wrapper.ts:The PR description notes this was previously broken in dev, where
buildId = "development"meant the same cache key was used across deployments.deploymentIdis now threaded through the build pipeline, work store, andAppRouteSharedContext.Test fixture:
test/production/app-dir/use-cache-cross-deployment/(asserts that changingNEXT_DEPLOYMENT_IDorBUILD_IDproduces different cache keys, including across the default cache handler).Why this matters for vinext
vinext implements
"use cache"and ships a KV-basedCacheHandlerfor Cloudflare Workers. To match Next.js parity:"use cache"cache keys must incorporate the deployment identifier so that different deployments do not share cached results.CF_VERSION_METADATA(or a build-time environment variable equivalent toNEXT_DEPLOYMENT_ID).buildIdshould be preserved, and the existingbuildId = "development"problem should be considered for vinext dev mode as well.Action items
deploymentIdvalue through vinext's"use cache"work store / cache key derivation, mirroringworkStore.deploymentId || workStore.buildId.NEXT_DEPLOYMENT_ID) and/or the Workers version metadata when running on Cloudflare.test/production/app-dir/use-cache-cross-deployment/.References
cacheHandlerskeys vercel/next.js#93453