AI & Agent Dev Bug Sandbox logo
AI & Agent Dev Bug Sandbox
Back to Radar

Changed DeploymentIds And SWR Caching Causes Mixed Fetches On Clients After Redeploy

Client-side navigation to ISR pages can serve stale RSC payloads from browser cache without contacting the server, leading to mixed module versions and runtime errors after redeployment.

highConfidence 72%Next.jsAffected V16.3.6Affected V16.4.0-Canary.61

Origin Analysis

Next.js sets Cache-Control headers with stale-while-revalidate on RSC responses, allowing the browser to serve cached RSC payloads optimistically. The server never receives the request, so the deploymentId mismatch between client and server is not detected, and the client loads a mix of old and new chunks.
1. Run `./scripts/deploy.sh build-a` with DEPLOYMENT_ID=build-a.\n2. Open `http://localhost:3000/` in Chrome with DevTools Network open and cache enabled.\n3. Click 'Go to /other' (client navigation to ISR page, revalidate=3600).\n4. Stop server, run `./scripts/deploy.sh build-b` on same port.\n5. Open new tab at `http://localhost:3000/` (shows build-b), click 'Go to /other', observe network: RSC payload served from cache without revalidation and mixed chunks cause errors.

Fixing Code Block

Edge Case Audit

This disables client-side caching for RSC payloads entirely, increasing network traffic and server load. It may not work if route handlers or subsequent middleware overwrite the header; consider using a reverse proxy for guaranteed enforcement. Rolling back requires removing the middleware and any cached entries. If using a CDN, ensure it does not strip or override the header.

Ecosystem Topology