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

> My opinion is that "once a write() has dispatched, the returned status always depends on the underlying sink" is the easiest semantics to implement and understand.

That's not quite correct though, since the underlying sink could call `controller.error()`, but we plan to ignore that. It's more, "the returned status always depends on the return value of the underlying sink's `write()` method."

> This is the most informative behaviour, but also could be a trap for content authors expecting nothing else to happen after the .closed promise resolves.
> 
> Additional peculiarity: normally write()s resolve in strict calling order, but on error one write() may resolve out-of-order.

Ooh, these seem pretty bad :(. (I don't quite understand how the latter could arise, though.) Maybe we could delay .closed until the write() fulfills or rejects?

> "reject on successful cancel" sounds strange but it's really "reject on write did not happen" which is the normal expected behaviour.

Agreed, although I am not 100% sure about the unable-to-determine-the-outcome case.

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