Prevent synchronous IO from entering Cached Navigations

[unstubbable]

Cached Navigations incorrectly reused uncached timestamps as static page content. A repeat visit showed the previous request's Date.now() result while the new response was still pending. This affected both dynamic RSC responses and the RSC payload embedded in the initial HTML.

The production renderer left synchronous IO untracked because it assumed the build had already checked it. A private cache exposed the gap: the static prerender suspended at the cache call and never reached the Date.now() after it. A production request resolved the private cache during the static stage and included the uncached timestamp in the reusable response.

Production staged renders now end the static stage when synchronous request-time IO occurs. They mark the interrupted static and shell prefixes as empty, while the rest of the response renders normally. The client skips those prefixes instead of waiting for a Flight root that the interrupted stage may not have emitted.

The regression tests cover dynamic RSC navigation, initial HTML hydration, and full prefetching with a paramless private-cache fixture.

[github-actions]

Tests Passed

Commit: df000df

[lubieowoce]

why is this needed? StagedRenderingController already gets out of Static when we hit sync IO:

next.js/packages/next/src/server/app-render/staged-rendering.ts

Lines 176 to 180 in afb0dba

	// If we're in a non-abandonable & non-abortable render,
	// we need to advance to the Dynamic stage and capture the interruption reason.
	// (in dev, this will be the restarted render)
	this.syncInterruptReason = reason
	this.advanceStage(RenderStage.Dynamic)

so any content emitted after twouldn't make it into the cached nav anyway

and just because it was aborted prematurely doesn't mean it'll be useless, because it may have been in a suspense boundary. sure, we'd error for this in build, but having some content seems better than none at all?

[lubieowoce]

oh did this hang in decodeBufferedStage because the root is blocked? in that case we should probably just reject the decode after setTimeout(_, 0), that's not the only scenario that can block the root. e.g. we can have

export default async function RootLayout({ children }) {
  // not blocking during build, blocking after revalidation
  if (await cacheThatBecomesTrueAfterRevalidation()) {
    await dynamicData() 
  }
  // ...
}

which (off the top of my head, untested) should be fixed by something like this:

export function decodeBufferedStage<T>(
  buffer: Uint8Array,
  headers: RequestHeaders | undefined
): Promise<T> {
  const stream = new ReadableStream<Uint8Array>({
    start(controller) {
      controller.enqueue(buffer)
      controller.close()
    },
  })
  return new Promise<T>((resolve, reject) => {
    // The stream is buffered, so the decode should yield a root microtaskily.
    // If it doesn't, then the root must be blocked.
    const timeout = setTimeout(() => {
      reject(new Error('Root is blocked.'))
      stream.cancel()
    });

    createFromNextReadableStream<T>(stream, headers, {
      allowPartialStream: true,
    }).then((root) => {
      clearTimeout(timeout)
      resolve(root);
    }, reject);
  });
}

(we may also just want to return a hanging promise, but if we know it's useless bc it blocks, then i guess there's no point)

[lubieowoce]

may want to use getSyncIOMode(prefetchMode) for consistency. in PPF we only allow sync IO in the dynamic stage so if we hit some at any point we should go straight to dynamic

...not that it matters very much, because we don't care about recovering stages past Static here anyway, but at least then it won't look like an exception when it really doesn't need to be