Stale Route-Cache After In-Place Deploy Due To Build-Independent Cache Key In Next.Js 16.3.8+

PR #99482 altered the key generation in route-cache-key.ts such that it no longer incorporates a build-specific identifier (e.g., build ID or asset hash). As a result, previously cached responses for routes remain keyed identically across different builds, so an in-place deploy that preserves .next/server/route-cache will serve stale redirects or asset references from the old build.

1. Clone https://github.com/mcdado/next-route-cache-stale-repro 2. npm install 3. Run ./repro.sh 4. Observe that after deployment, some pages load stale asset URLs and return 404 for CSS/JS files.

This hotfix invalidates the entire route cache on every deploy, which may cause a temporary performance degradation as caches are repopulated. In multi-process or multi-instance deployments sharing the same .next directory, concurrent deletion and writes can cause race conditions. When rolling back to an older version, this deletion step may still be safe but should be tested, as older versions might expect a persistent cache. A better long-term fix is to include the build ID in the cache key, allowing caches from different builds to coexist.