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

(a) I agree that it's more natural that an aborted writable stream says "hey, I'm broken" than "I'm closed". It's good to have them behave nicely so that developers who made mistake get the most useful signal from them.

But we can have similar argument against `readableStream.cancel()`. Readable stream's "closed" state means end-of-data for normal cases. A cancelled stream is not telling us that it reached the end-of-data.

(b) If we have any logic that tries to do something further after .abort(), .cancel(), that's just wrong. If there's a fulfillment callback set to readableStream.closed, it should be neutered when we call readableStream.cancel(). Similarly, any code that is waiting for writableStream should be neutered when we're calling writableStream.abort().

> if you are throwing away queued data, something has likely gone wrong, and other parts of your program (mostly those that use writer.closed) should probably go down the error-handling path.

This makes me feel that an aborted writable stream looks more inappropriate target to touch than a cancelled readable stream, yeah ... but ... very very subtle. Both are basically wrong.

----

The current setup has 2 points look strange to me:
- (1) inconsistency between abort() and cancel(). cancel() is backed by (b) but abort() is backed by (a)
- (2) the reason passed to .abort() is set to storedError and reflected back to the producer.

(i) Ideally I'd like to change cancel() to enter "cancelled" state and make methods throw/reject with TypeError("Cancelled") and make abort() to enter "aborted" state and make methods throw/reject with TypeError("Aborted"). This solves both (1) and (2) and satisfies (a). As we're likely not to expose the state, there wouldn't be any additional complexity (additional state "aborted" and "cancelled"). but we cannot revert .cancel()'s behavior now. It's already shipped. Too late.

(ii) Changing abort() to transition to closed solves (1) and (2) but doesn't satisfy (a).

(iii) Changing abort(reason) not to set reason to storedError but set it to TypeError("Aborted") solves (2) and satisfies (a).

I've been suggesting (ii) but could also live with (iii) honoring importance of (a).


---
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-224880847