Allow cancelling React SSR rendering without aborting the response transport

[DeyLak]

We want to impose an SSR render budget while the browser remains connected: stop pending React rendering, flush its Suspense fallbacks, and let the router finish streaming hydration data and close the document.

renderRouterToStream currently uses request.signal for both React rendering and transformReadableStreamWithRouter. Aborting it cancels the response transport too. That is appropriate for a disconnected client, but prevents using the same renderer adapter for a render-only deadline.

Would an optional renderer signal be an acceptable API?

renderRouterToStream({
  request,
  router,
  responseHeaders,
  children: <StartServer router={router} />,
  renderSignal: renderBudget.signal,
})

Proposed semantics:

• request.signal retains its current meaning and cancels the whole response.
• renderSignal only stops React; the router serialization/HTML transport keeps draining.
• Without renderSignal, behavior stays unchanged.
• Disconnecting the client still cancels rendering even when a separate render signal is supplied.
• If cancellation happens before React's shell is ready, including an already-aborted signal, reject with the original renderSignal.reason; the application chooses its fallback response and HTTP status.
• After shell readiness, let React flush pending-section fallbacks/client-render instructions while Router continues serialization. The signal alone does not select a new HTTP status.
• Expected render cancellation should not be logged as a renderer failure; unrelated failures should remain reportable. No new public cancellation-error type is proposed.

The minimal proposal changes only renderRouterToStream. As a possible additive extension, defaultStreamHandler could also accept and forward renderSignal, avoiding a custom render callback at the application boundary. That higher-level convenience is not required by the initial proposal; I would welcome maintainers' preference on it.

The application would still choose its render budget and settle its deferred data sources. Router would provide the rendering-cancellation mechanism; application data loading and retries would remain application-owned.

We observed the shared-signal wiring in @tanstack/react-router@1.170.46 and the same renderer source on main when checked. This is an API proposal, not a claim that cancelling a real request should keep its response alive.

Related but different: #7909 concerns abandoned-stream watchdog expiry, #7674 concerns missing bootstrap data, and #7714 proposes broader per-request streaming policy.

Is renderSignal a reasonable seam, or is there an existing supported way to achieve this without copying the renderer adapter? Would you prefer the minimal renderer option, or also forwarding it through defaultStreamHandler?

AI-assisted proposal.