Re: [whatwg/streams] Always resolve tee's cancel promise after reaching end of stream (#1039)

@MattiasBuelens commented on this pull request.



> @@ -2089,6 +2090,7 @@ create them does not matter.
      |r|).
   1. Perform ! [$ReadableStreamDefaultControllerError$](|branch2|.\[[readableStreamController]],
      |r|).
+  1. [=Resolve=] |cancelPromise| with undefined.

Need some input on this: when the original stream errors while one of the two branches is canceling, should we *resolve* or *reject* the cancel promise? 🤔 

For a regular stream, when you call `controller.error(e)` while canceling, the error does not affect the promise returned by `cancel()` in any way. (Maybe it should? But that's a different discussion.) [ReadableStreamCancel](https://streams.spec.whatwg.org/#readable-stream-cancel) immediately sets the stream's state to `"closed"`, and [ReadableStreamDefaultControllerError](https://streams.spec.whatwg.org/#readable-stream-default-controller-error) does nothing if the state is not `"readable"`. The only thing that *can* affect the promise returned by `cancel()` is... well, the *sourceCancelPromise* returned by `source.cancel()`. 😛

For a tee'd stream, I'd say that `controller.error(e)` should at least let any branch finish canceling. The original stream ends up in a terminal `"errored"` state, similar to how `controller.close()` puts it in a terminal `"closed"` state. So I *think* resolving the cancel promise should be acceptable...?

-- 
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/pull/1039#pullrequestreview-430025555