Skip to content

[pull] canary from vercel:canary - #1256

Merged
pull[bot] merged 2 commits into
code:canaryfrom
vercel:canary
Jul 31, 2026
Merged

[pull] canary from vercel:canary#1256
pull[bot] merged 2 commits into
code:canaryfrom
vercel:canary

Conversation

@pull

@pull pull Bot commented Jul 31, 2026

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

acdlite and others added 2 commits July 31, 2026 00:37
When a static fallback shell is served as-is — e.g. from a CDN in a
deployed environment — the client can't hydrate from inline Flight data;
it fetches the full RSC payload separately and reconstructs the initial
payload on the client. During that reconstruction, the head's partiality
flag was accidentally set to the head itself. Since the head is always
truthy, the head was unconditionally treated as partial.

This happens to be unobservable today: the only flows that reach the
reconstruction are fallback-shell prerenders, where the server
pessimistically marks the head partial anyway, and when Cache Components
is enabled the client ignores the per-payload flag entirely in favor of
response-level partiality. But we're about to rework the RSC response
format so that head partiality has a single, load-bearing source of
truth, so the flag needs to survive the reconstruction correctly rather
than by coincidence.

While auditing the payload consumers, I also fixed the payload shape
check in segment prefetch generation (it used `&&` where `||` was
intended, so it accepted any shape) and deleted
`should-hard-navigate.ts`, which no longer has any callers on the
client.

Adds e2e coverage asserting that metadata survives hydrating a fallback
shell page: the title is correct after hydration, the head is included
in prefetched data, and a return navigation is served entirely from the
cache that was populated during initial hydration. In deployed
environments this exercises the client resume path, which is where the
reconstruction runs.
Built using @sokra's Fleet! This re-arranges all of our chunking
experimental features under `experimental.turbopackChunking` and adds
the following options:

```javascript
/**
 * Avoid creating more than one chunk smaller than this size, in bytes. Smaller
 * chunks are merged into bigger ones to avoid that. Defaults to `50000` (50 KB).
 */
minChunkSize?: number
/**
 * Avoid creating more than this number of chunks per chunk group. Chunks are
 * merged into bigger ones to avoid that. Defaults to `40`.
 */
maxChunkCountPerGroup?: number
/**
 * Never merge chunks bigger than this size, in bytes, with other chunks. This keeps code
 * in big chunks from being duplicated across multiple chunks. Defaults to `200000` (200 KB).
 */
maxMergeChunkSize?: number
/**
 * Minimum size, in bytes, for a component chunk to be emitted on its own when
 * `generateComponentChunks` is enabled. Component chunks smaller than this are folded into a
 * single remainder chunk. Defaults to `20000` (20 KB).
 */
minComponentChunkSize?: number
```
@pull pull Bot locked and limited conversation to collaborators Jul 31, 2026
@pull pull Bot added the ⤵️ pull label Jul 31, 2026
@pull
pull Bot merged commit b4e3fec into code:canary Jul 31, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants