Handling _rsc Cache Keys

[wp99cp]

Problem: In rscCaching, you strip the _rsc value: params.set('_rsc', '').

Next.js uses the _rsc query param (often a hash) to ensure the client receives the correct flight segment version for the current build/tree.
Risk: If you deploy a new version of the app, key stripping might match an RSC payload from a previous deployment (if the path is the same). This can lead to hydration errors or broken UI if the client code expects a different RSC structure.

[wp99cp]

Re-checked against origin/dev (78c5035c) in a clean worktree.

Short answer: the exact line is gone, the underlying problem is not.

The cited code no longer exists

3bf6998d (refactor(offline): simplify SW caching by delegating RSC stream handling to Next.js 16.3 Network Resilience) removed the cacheKeyWillBeUsed hook with params.set('_rsc', '') from rscCaching. That strategy is now NetworkOnly (src/features/service-worker/offline-support/caching.ts:85-91), so nothing on the runtime-caching path writes RSC payloads under a stripped key anymore.

But the same normalization just moved

The write side is now in the offline prefetch, and it is looser than what the issue described:

• prefetch.ts:309-312 — fetches with ?_rsc (empty value).
• prefetch.ts:366-371 — writes three keys per page: …?_rsc, <origin><cleanAppPath>?_rsc, and <origin><cleanAppPath> with no _rsc at all.
• rsc-utils.ts:40-46 — getNormalizedRscUrl strips the value on read. Its doc comment still says "Matches the logic used in caching.ts 'cacheKeyWillBeUsed'", which is now stale — that function is gone.

And no build scoping anywhere: CACHE_NAMES.RSC is the literal 'next-rsc-cache-v1' (constants.ts:4), with no build/deployment id. The activate handler (sw.ts:57-79) only prunes cache names not in CACHE_NAMES, so the RSC cache is explicitly preserved across deployments. There is no generateBuildId / deploymentId in the repo either.

The blast radius is narrower than originally feared

matchCachedRsc is reachable from exactly one place: offlineFallback (fetch-handler.ts:177). So a cross-build payload can only be served when the device is offline, the network fetch throws, or the App Mode fetch hits its 3s timeout. Online users after a deploy get NetworkOnly / network-first and are unaffected. That's a real improvement over the state the issue was filed against.

Mitigation on deploy exists but is partial: sw.ts:82-94 re-runs prefetchOfflinePages() on activate when offline support is enabled, overwriting those keys with fresh payloads. Caveats — it's fire-and-forget (void), it only covers offlinePages + registry URLs, and it never touches entries written by the App Mode path (fetch-handler.ts:479-495), which key by the full URL including the real _rsc hash and are never pruned. Those accumulate indefinitely and, after a deploy, can no longer be hit by exact match — only by the loose fallbacks below.

The loose fallbacks are the bigger problem

matchCachedRsc steps 4 and 5 (rsc-utils.ts:87-119) match by pathname alone across all cached keys, and step 5 deliberately returns a different route's shell payload (/app/schedule/123 → /app/schedule). These bypass key discipline entirely — build-scoping the cache key does nothing unless these two paths are scoped too.

Suggested resolution

1. Put the build id into CACHE_NAMES.RSC (or caches.delete(CACHE_NAMES.RSC) on activate when the build changes) — cheap, since the content is re-prefetched anyway.
2. Make the pathname/shell fallbacks skip entries from a different build.
3. Fix the stale comment in rsc-utils.ts:37-38.

Note this is a code-reading assessment, not an empirical repro across two deployments.