[whatwg/streams] pipeTo(): Rationale for propagating an error happened during error prpopagation to pipePromise (#558)

Forked from https://github.com/whatwg/streams/pull/512#issuecomment-255345690

I'd like to record how we concluded to adopt this semantics.

`.pipeTo()` propagates error in both forward and backward direction by calling `.abort()` and `.cancel()` respectively. Before #512, I implemented it to throw away any error during the error propagation and reject the `pipePromise` with the original reason.

Domenic proposed that we change it to propagate an error happened during error propagation to `pipePromise` with explanation of the rationale at https://github.com/whatwg/streams/pull/512#discussion_r83466000. I understand Domenic's point that "both errors are seen by someone" is important.

So, when the destination WritableStream is errored during pipeTo() with `preventCancel` set to falsy:
- if the propagation (`reader.cancel()`) is successful, the `pipePromise` gets rejected with the original error
- otherwise, the `pipePromise` gets rejected with the error in `reader.cancel()`. In this way, the error in `reader.cancel` is seen via `pipePromise` while the original error can be obtained by looking at the destination WritableStream even when the propagated original error hasn't successfully remembered by the source ReadableStream.

I personally think it's a bit inconvenient that we need to check the destination writer to see the original reason and prefer e.g. making the resolution of `pipePromise` be a structure (even an Array is fine) to be able to hold both the original error and optionally an error during propagation if any. This would make the interface complicated, and is not based on real experience in application development.

So, we're going to adopt Domenic's idea, but we appreciate if you could comment to this issue when you have any other rationale or encounter any real situation which would support either of the approaches.

-- 
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/558