streams icon indicating copy to clipboard operation
streams copied to clipboard

Piping should not try to write if there is an error queued

Open domenic opened this issue 8 years ago • 1 comments
trafficstars

Similar to https://github.com/whatwg/streams/issues/727, but this affects the spec, not just the reference implementation.

After https://github.com/whatwg/streams/pull/726 lands, pipeTo() will say to write anything that was read, unless there is a close queued, or the stream is errored/closed.

But we should also handle the case of there being an error in progress. Currently this means an abort is queued, but after #721 things in that area will be more uniform, so we should wait to fix this until that lands.

Probably when we do so we'll want to factor out some writable stream abstract op like WritableStreamCouldWriteSucceed() and use that in write() and in the two branches of pipeTo().

In practice the impact here is not so big: basically it avoids an extra trip to the writer, which will immediately throw away the attempt at writing. I'm not even sure if it's testable.

domenic avatar Apr 06 '17 12:04 domenic

The standard is (intentionally) ambiguous on how writing is done, so "somehow force the write to happen anyway even though it would normally be disallowed" might be one interpretation.

ricea avatar Apr 06 '17 12:04 ricea