next.js

8c6cb0e0 - [PP] Reveal after ShellRuntime when simulating a Shell Prefetch in dev (#95149)

[PP] Reveal after ShellRuntime when simulating a Shell Prefetch in dev (#95149) When `partialPrefetching` is on, the shell that we usually care about displaying is the App Shell, which is represented by the ShellRuntime stage. We should only show the cold cache indicator for caches that happen up until then, and release the client-side promise appropriately. This PR extends the existing `revealAfterStage` mechanics to account for this. > Note that this is incomplete: if we're navigating via `<Link prefetch={true}>` (or have `partialPrefetching: "unstable_eager"), we might want to use the Runtime stage instead. I'm leaving those for a follow up -- representing the common case (a shell prefetch) seems like the most useful thing. I've re-worked the `revealAfterStage/holdStreamUntilRevealed` setup into an object (`DevNavigationKind`) that represents the navigation that we're trying to simulate -- either an initial load or a client nav. This gets rid of the invalid `holdStreamUntilRevealed = true` + `revealAfterStage = RenderStage.Runtime/ShellRuntime` combination and lets us bring the logic closer to where the stream blocking tricks actually happen. I've also done some drive-by refactoring of `streamStagedRenderInDev` to dedupe some repetitive code, because every task was basically doing the same thing. I've also moved all `revealAfter.resolve()` calls into separate tasks -- we were inconsistent about this, and the `Static` `revealAfter.resolve()` was done together with the next stage, but the `RenderStage.Runtime` was done in a separate task. --- Strangely, despite the changes working as expected for the Cold Cache indicator, I can't actually get link data (`await searchParams`) to trigger a fallback when navigating, so there's a failing test for that in `cache-components-dev-streaming.test.ts`. I'm not sure why what's causing this, but I'm leaving that investigation for a follow-up as well.