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

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

I'm ok with that. After several discussions, we have consensus that write() promise should represent the ongoing operation. Yes.

> I think I agree with you that it'd be better to just disallow abort() during close().

Oh, no. Sorry if the first sentence of my post gave some nuance that I'm stating objection also in the third sentence. I just wanted to say that it seems we should align `.closed`'s transition for `abort()` on ongoing `close()` with the proposed behavior of `abort()` with ongoing `write()`. I.e. if `underlyingSink.close()` says it was successful even though it also received `underlyingSink.abort()` call, we should fulfill `.closed` with undefined even if `.abort()` was called while `.close()` is ongoing. I didn't mean that we should ignore `abort()` when there's an ongoing `close()`.


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