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.

The slightly surprising part is that write() may fulfill long after everything else has ended. 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. From a standard/implementation point of view, tracking "what kind of abort is this" adds considerable complexity, and may even be intractible. It's possible that whether a write() should succeed or fail in a particular scenario is subjective.

Additional peculiarity: normally write()s resolve in strict calling order, but on error one write() may resolve out-of-order.

If a sink is capable of cancelling an in-progress write on abort() then they should do so. I think platform-supplied sinks should always return a rejection if they successfully cancelled the underlying write operation or are unable to determine the outcome, and fulfill if the write operation completed. "reject on successful cancel" sounds strange but it's really "reject on write did not happen" which is the normal expected behaviour.

Underlying sinks provided by content authors can of course do whatever works for them, but hopefully will tend to match the platform behaviour.

I see two reasons for an underlying sink to implement abort():

1. To cancel the underlying write() operation, and/or
2. To signal the error condition to the underlying layer.

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