Repository navigation
fix(web): keep RSC payloads out of the browser's HTTP cache (web 0.65.1) - #640
Merged
Merged
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
 |
After a deploy, the first client navigation to a prerendered page could crash with React error #306. Next marks prerendered pages stale-while-revalidate for a year with no max-age, and the router's _rsc URL depends only on request headers, so Chromium served the previous build's RSC payload from its HTTP cache. Next rejects it on the build id, but decoding it has already loaded the old build's chunks, and Turbopack keeps the first factory it registers for a module id. A module both builds share stayed the old version, so a new export of it (PaidPlanCTA) resolved to undefined. Every RSC request now gets private, no-store Cache-Control; page HTML keeps Next's own header. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The test helper now compiles sources with modifyRouteRegex, as the router does, so "/:path*" matches the root and the RSC rule needs no separate "/" entry. The prefetch case sends the segment cache's route tree prefetch, the request that brought in the stale payload. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kroqdotdev
changed the title
kroqdotdev
force-pushed
the
fix/rsc-payload-browser-cache
branch
from
November 10, 2026 14:44
f62e415 to
b111467
Compare
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Right after a deploy, the first client-side navigation to a prerendered page could crash into the app error boundary with React error #306 ("Element type is invalid. Received a promise that resolves to: undefined"). Reported once, on the 0.63.0 deploy, for a dashboard to landing page click in a Chromium browser; a reload fixed it.
Cause
s-maxage=600, stale-while-revalidate=31535400with nomax-age, and the router's?_rsc=URL is a hash of request headers only, so it is identical across builds. Chromium's private HTTP cache honours the stale-while-revalidate window and serves the previous build's RSC payload once.components/landing/pricing-cta.tsx) stays the old version.PaidPlanCTA, new in 0.63.0, which the old factory never exports, so the client reference resolves toundefined: chore(deps): bump quinn-proto from 0.11.14 to 0.11.16 in /apps/receiver-rs #306.Reproduced locally with production builds of 0.62.9 and 0.63.0: visit on the old build, swap servers, reload the dashboard, click the logo, and the error page shows with #306.
Fix
next.config.tssetsCache-Control: private, no-cache, no-store, max-age=0, must-revalidateon every request withRSC: 1(prefetch or navigation; Next compiles/:path*so it matches/too). Next only sets Cache-Control when none is set, so this wins. Page HTML keeps Next's own header; Cloudflare already treats these responses as dynamic, and Next's server-side ISR cache does not depend on the header.With the fix in both builds, the same old-to-new swap renders the landing page with no errors.
Note: browsers already holding 0.63.0 payloads can still hit this once on the first navigation after this release deploys; from the following deploy on it is covered.
Tests
next.config.test.ts: RSC requests (a navigation and the segment cache's/_treeprefetch) to/,/dashboard,/docs/agents,/webhooks/stripeget the no-store header; page HTML and email templates keep their current Cache-Control. The helper now honourshasconditions and compiles sources withmodifyRouteRegex, as Next's router does. Without the fix 4 tests fail.Web 0.63.1 with a changelog entry.
🤖 Generated with Claude Code