Should terminating a worker close/error streams?

[saschanaz]

I found that Firefox currently explicitly closes new Response(...).body when the owning worker closes: https://searchfox.org/mozilla-central/rev/9de332d5c8faac58dc1232b8a6383ce6cb1400f4/dom/base/BodyStream.cpp#169

But for general streams AFAICT both Firefox and Chrome do not close nor error the stream, and just let the read requests stall forever when trying to read streams transferred from terminated workers.

But should worker termination ping the streams what's happening? This will expose worker GC, but Web Locks already exposes that information.

cc @asutherland

[domenic]

I don't think streams, which are a basic data structure-ish primitive, should have hooks into environment-specific termination signals like this.

If specific streams, e.g. response body streams, want to add such hooks, that's reasonable. (But, their spec should be updated to include that.)

[saschanaz]

While that sounds reasonable, wouldn't it be a footgun for other Stream-using specs when the core Streams spec doesn't cover it? File System and WebTransport may also need to deal with this themselves for example.

(Depends on whether we should do this at all, though.)

[domenic]

Hmm, fair. If this is something we should do (I am still not clear), then it should be as part of the other-spec wrapper algorithms, IMO.