[GH-ISSUE #1064] Include deploymentId in "use cache" cache key #233

New issue

Open

opened 2026-05-06 12:38:24 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-06 12:38:24 +02:00

Owner

Originally created by @github-actions[bot] on GitHub (May 5, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/1064

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

Plumb a deploymentId value through vinext's "use cache" work store / cache key derivation, mirroring workStore.deploymentId || workStore.buildId.
Read the deployment id from a documented env var (e.g., NEXT_DEPLOYMENT_ID) and/or the Workers version metadata when running on Cloudflare.
Verify that the dev server does not reuse cache entries across restarts when no deployment id is configured (or document the dev-mode behavior).
Port the cross-deployment cache key test from test/production/app-dir/use-cache-cross-deployment/.

References

Originally created by @github-actions[bot] on GitHub (May 5, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/1064 ## Upstream change Next.js commit [07f76411b07de9417d4a6b816f3137cafe1045fc](https://github.com/vercel/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`: ```diff - 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 - [ ] Plumb a `deploymentId` value through vinext's `"use cache"` work store / cache key derivation, mirroring `workStore.deploymentId || workStore.buildId`. - [ ] Read the deployment id from a documented env var (e.g., `NEXT_DEPLOYMENT_ID`) and/or the Workers version metadata when running on Cloudflare. - [ ] Verify that the dev server does not reuse cache entries across restarts when no deployment id is configured (or document the dev-mode behavior). - [ ] Port the cross-deployment cache key test from `test/production/app-dir/use-cache-cross-deployment/`. ## References - Commit: https://github.com/vercel/next.js/commit/07f76411b07de9417d4a6b816f3137cafe1045fc - PR: https://github.com/vercel/next.js/pull/93453