Re: [whatwg/streams] Cancelling and exception handling async iteration of ReadableStreams (Issue #1255)

> I think the best case is if your stream-creator takes an AbortSignal, and uses that appropriately throughout the chain. fetch() does that.

That's true, but `fetch()` only rejects during the request phase. Once we've got a response, the readable body stream gets cancelled by abort. Any pending read just resolves with `{ done: true, value: undefined }`. It's more as though `fetch()` accepts a signal to use for aborting the writable end of a transform stream into which it dumps the response. The readable stream doesn't really need to know anything about abort.

I've just had a chance to refactor some code that was using async iterables and generators to use streams and I don't think it makes sense to add an abort signal to stream constructors. Calling `abort()` or `cancel()` is the way to cancel the stream. Whether that's driven by an `AbortSignal` is the user's decision. Whether the stream uses an `AbortSignal` internally for cleanup is the stream implementor's decision.

However, it might be common enough that cancelling a readable stream should abort an in-flight pull that providing a signal on the controller would be a convenience and improve symmetry with writable streams. There are other asymmetries between readable and writable stream, the nuance of which I might not fully appreciate yet, and I don't know if the signal is part of that.

Calling `abort()` on a writable stream first waits until any in-flight write settles, then it finishes by awaiting the abort steps defined by the sink. Meanwhile, calling `cancel()` on a stream just awaits the cancellation steps defined by the source. Pending read requests settle immediately with `{ done: true, value: undefined }`.

If we did want to add a signal to the readable controller, does it then become important that the signal be a way to abort an in-flight pull, and should cancellation therefore wait for that? I think the spec would maybe want to break cancellation into two phases like it does with writable streams. In the first phase, an in-flight pull would get a chance to resolve, then the second phase would be as cancellation is now.

That seems like a more invasive change that deliberate breaks the asymmetry, and then I'm left wondering why `cancel()` vs `abort()` / `close()` at all?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1255#issuecomment-2048481036
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1255/2048481036@github.com>