Re: [whatwg/streams] [WritableStream] Shouldn't the state after writer.abort() be closed? (#464)

> This would cancel rs, clearly, but I am not sure whether it should abort or close ws. Hmm. I guess that could even be an option that you pass to cancel().

Agreed. Similar to normal completion case for which we already have prevent.* options.

> The way I originally envisioned ...

Yeah, that's not different from one in my mind. I posted [this](https://github.com/whatwg/streams/issues/464#issuecomment-223197040) just to explain how (I remember) I was convinced by you with why `ws.abort()` should make `ws` errored. My proposal doesn't break error propagation by `pipeTo()` itself. Left to right propagation is done by `writer.abort()` call on transform.writable. The transform stream machinery would forward the signal to `pipeTo()` machinery by erroring `transform.readable`. It'll be propagated to result in `ws.abort()` call. My proposal doesn't affect this.

> I do not think it is inherently important that transform.writable become errored and that transform.readable become closed.

Agreed. In general, to what state (state visible on WritableStream I/F. Not about the sink and internal state) `ws` transitions to on `writer.abort()` and what state (state visible on ReadableStream I/F. Not about the source and internal state) `rs` transitions to on `reader.cancel()` are not so important. Consumer and producer facing the stream interface should know what they did. So, my proposal doesn't solve any real issue but kinda based on preference and consistency.


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