Re: [whatwg/streams] Aborting a writable stream should not abort writes in progress (#611)

> I had been thinking that .abort() should make the WritableStream to mark everything on it including .closed , pending .write()s and active .write() as aborted. I.e. almost in the same expectation as .cancel().

This is certainly simpler. But I think it is not as good for the producer, because they see .write() rejecting and everything shutting down immediately when in fact the underlying sink is still busy writing data to the filesystem or wherver. That is what motivates the change.

But I am still sympathetic to maybe not making this change if we just want to keep things simple. Maybe it will not impact people in the real world much. When they are aborting their writable streams maybe they do not care about whether or not the write succeeded.

> Wait for the active .write(), reject all the pending .write()s and then .closed.

Yeah, this sounds good.

> One more point we should clarify. If the in-flight operation is .close(), we abort()-ed but it finished successfully, I think we should move the WritableStream into "closed" state as well as .write()s fulfills regardless of .abort(). Do you agree?

Interesting. I think we discussed this before. We even have a note in the spec:

> Due to the way writable streams asynchronously close, it is possible for both close and abort to be called, in cases where the producer aborts the stream while it is in the "closing" state. Notably, since a stream always spends at least one turn in the "closing" state, code like ws.close(); ws.abort(...); will cause both to be called, even if the close method itself has no asynchronous behavior. A well-designed underlying sink object should be able to deal with this.

I think I agree with you that it'd be better to just disallow abort() during close(). But this note implies to me that we thought through this and came to the opposite conclusion in the past.  It looks like the discussions are in:

- https://github.com/whatwg/streams/issues/130
- https://github.com/whatwg/streams/pull/192
- https://github.com/whatwg/streams/pull/224
- See especially https://github.com/whatwg/streams/issues/130#issuecomment-53506871 proposals 1-3.

I guess the question is whether we think abort() should be able to abort a long-running underlying sink close (with no cooperation from the underlying sink). Probably we should have the same answer for a long-running underlying sink close as we do for a long-running underlying sink write.

---

I guess at this point I am on the fence as to whether this change is worth making. I will review @ricea's branch on the assumption that it is. But if anyone has strong feelings about how abort() should behave, that would be helpful, as I am no longer sure myself.

-- 
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/611#issuecomment-261667250