Re: [whatwg/streams] pipeTo() algorithm shuts down too early on readable close()? (#644)

> I think there's an issue with the pipeTo() algorithm that prevents writing all the data. When the underlying source calls close() the state of the ReadableStream changes immediately to "CLOSED". If there is a read() on the readable ongoing at that point then pipeTo shutdown starts immediately, prohibiting the data that was read from being written to the WritableStream.

It sounds like the problem is in "Shutdown must stop all activity". We want any reads to always be followed by writes... as long as the dest is "writable", I guess. Shutdown says "Wait until any ongoing write finishes" already, but if the write isn't ongoing yet that doesn't work.

> A related problem is that if the source queues several items and calls close(), then the sink errors while writing one of those items, the standard implies that since the readable became CLOSED first, pipeTo should fulfill without error. I think it should reject with the error from the sink.

I think this works with the current spec:

- close() ends up in "Closing must be propagated forward"
- We go to "shutdown with an action" of WritableStreamDefaultWriterCloseWithErrorPropagation(writer).
- We wait for any ongoing writes to finish. One errors, causing dest.[[storedError]] to be set.
- We let p be the result of performing WritableStreamDefaultWriterCloseWithErrorPropagation(writer).
- p is rejected with dest.[[storedError]].
- We finalize with dest.[[storedError]].

-- 
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/644#issuecomment-272483597