[GH-ISSUE #415] isr: namespace cache keys by buildId or deploy version #93

New issue

Closed

opened 2026-05-06 12:37:10 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-06 12:37:10 +02:00

Owner

Originally created by @Divkix on GitHub (Mar 10, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/415

Problem

ISR cache keys are currently formatted as <router>:<pathname> (e.g., pages:/about). When a new version of the app is deployed, the old cached entries may be served because the cache key hasn't changed. This can cause stale content from a previous build to be served to users.

Proposed Solution

Include buildId in the ISR cache key format: <router>:<buildId>:<pathname>.

The buildId is already available at runtime via process.env.__VINEXT_BUILD_ID (injected by the Vite define plugin). The change is to pass it through to isrCacheKey() and include it in the generated key.

This ensures that each deployment gets its own cache namespace, preventing stale cache reuse across deploys.

Acceptance Criteria

isrCacheKey() accepts optional buildId parameter
When buildId is provided, key format is <router>:<buildId>:<pathname>
Without buildId, format is unchanged (backward compat)
Long paths with buildId still hash correctly when exceeding length limit
All callers updated: dev-server.ts, pages-server-entry.ts
Tests cover all cases

Originally created by @Divkix on GitHub (Mar 10, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/415 ## Problem ISR cache keys are currently formatted as `<router>:<pathname>` (e.g., `pages:/about`). When a new version of the app is deployed, the old cached entries may be served because the cache key hasn't changed. This can cause stale content from a previous build to be served to users. ## Proposed Solution Include `buildId` in the ISR cache key format: `<router>:<buildId>:<pathname>`. The `buildId` is already available at runtime via `process.env.__VINEXT_BUILD_ID` (injected by the Vite define plugin). The change is to pass it through to `isrCacheKey()` and include it in the generated key. This ensures that each deployment gets its own cache namespace, preventing stale cache reuse across deploys. ## Acceptance Criteria - [ ] `isrCacheKey()` accepts optional `buildId` parameter - [ ] When `buildId` is provided, key format is `<router>:<buildId>:<pathname>` - [ ] Without `buildId`, format is unchanged (backward compat) - [ ] Long paths with `buildId` still hash correctly when exceeding length limit - [ ] All callers updated: `dev-server.ts`, `pages-server-entry.ts` - [ ] Tests cover all cases