[unstubbable]

Every server entry point that accepts a signal attached an abort listener to it and only ever removed that listener from inside the listener itself. On the success path the signal never aborts, so the listener stayed attached and its closure kept the whole Request, and therefore the entire rendered output, reachable for as long as the caller's signal lived.

This matters most for composite signals from AbortSignal.any() and for timeout signals, because the runtime retains those for as long as they carry a non-weak abort listener, and releases them only when the last listener is removed or the signal aborts. A composite passed to prerender() therefore became a garbage collection root holding a finished render for the lifetime of the process. A plain AbortController signal is never retained that way, but it still keeps the render reachable for as long as the caller holds the controller.

Each listener is now bound to a lifetime signal passed to addEventListener, so the runtime removes the listener as soon as that signal aborts and nothing has to track a teardown function. Flight reuses request.cacheController, which already aborts on a fatal error, at the completion of the flush loop (depends on #37342), and in abort(). Fizz has no equivalent, so it gains a renderLifetimeController that aborts at those same three points. processReply creates its controller only when a caller passes a signal, so a reply without one allocates nothing. Since abort() returns early once the request is past OPEN, removing the listener at those points cannot change observable behavior. The fifty-two copies of the listener block across the entry points collapse to a single attachAbortSignal call each.

Binding the listener to the render also covers a cancelled stream, which calls abort() without the request ever reaching a terminal status, so a teardown driven by that status would have left the listener attached. Fizz ends the lifetime in fatalError rather than at the CLOSING to CLOSED transition, because a shell error rejects before the caller receives a stream. Nothing then consumes the request, it never closes, and a listener waiting for that transition would never come off.

The two new controllers are aborted with an explicit reason. A call to abort() without one constructs an AbortError DOMException. Capturing the stack trace dominates that cost, and the cost grows with the depth of the stack, so every render and every reply would pay for an object that no code reads.

processReply no longer returns its abort function, because that return value existed only so each encodeReply implementation could wire the signal up itself, and nothing uses it now that the wiring lives inside. A reply whose model settles synchronously gets no listener, since aborting it was already a no-op.

The tests assert on the lifetime signal, because the runtime's removal does not go through removeEventListener and is therefore invisible to a patched signal. ReactFlightDOMNode-test asserts the removal itself with getEventListeners from node:events, which jsdom has no equivalent for.

Two cases stay open. A request whose stream is neither consumed nor cancelled never ends, and a reply with a part that never settles never settles either, so both keep their listener.

[gnoff]

If the stream is cancelled it doesn't seem like the request ever progresses to a terminal state and we still might not clean up the listener. might want to close that gap here or we can do a follow up

[gnoff]

might not be all that much better but you can apparently pass a signal to addEventListener. when it aborts the listener gets removed. We could then just model the render as having a lifetime and we always abort the renderlifetime controller when the render completes. functionaly it's the same thing though so maybe not worth it?

[unstubbable]

Nice idea, that made the cleanup much simpler. It also automatically handles the cancelled stream case.

[gnoff]

Hmm I think we are subtly wrong about flight having a suitable signal. This signal doesn't abort when the debug stream is still open but then later it also doesn't abort when the stream finally closes.

[gnoff]

or maybe it's just a bug in the cache lifetime signal itself

[unstubbable]

You mean #37342? I should have mentioned that this version of the PR relies on that fix.

[gnoff]

looks good since the cache life bug in flight server needs to be fixed anyway and can land independently