Re: [streams] First draft at tee algorithms, for critique (#302)

One question @yutakahirano brought up in https://github.com/whatwg/streams/pull/302#discussion_r26724967 is a good one. Consider the following situation:

```js
const rs = new ReadableStream({
  cancel() {
    throw new Error('wheee');
  }
});

const [branch1, branch2] = rs.tee();
branch1.cancel().then(/* what should happen here? (1) */);
branch2.cancel().catch(/* what should happen here? (2) */);
```

The semantics with regard to cancel is that if you cancel both branches, only then will we communicate back to the original stream that it should be cancelled, and will perform an action. That action might fail, as shown here.

### First cancel fulfills, second rejects

Maybe `branch1.cancel()` should fulfill. No actual stuff happened when you called branch1.cancel()---for all intents and purposes, branch1.cancel() is just a ref-count-decrease. That succeeded, and can fulfill immediately. Whereas, `branch2.cancel()` should reject, since it is a ref-count decrease *plus* the actual cancellation operation to the original underlying source.

### Both cancels reject

Maybe they should both reject: that is, maybe we should not resolve or reject either promise until the ref count has decreased to zero, and we can tell whether the original underlying source cancel succeeded or failed.

One possibly-unintuitive consequence of this is that if you only *ever* cancel branch1, then `branch1.cancel()` will stay pending forever (since we have to wait until branch2 cancels to resolve the promise).

### Both cancels fulfill

Maybe they should both fulfill: maybe we treat the success or failure of the actual underlying source cancellation as irrelevant, and say that the promise returned by `branchX.cancel()` just represents whether the ref-count was successfully decreased. Which it always will be.

The downside of this is that you lose any information about errors canceling the original underlying source.

---

It's important to keep in mind that this is a pretty small point. Many consumers will not care if canceling fails (or succeeds). The whole point of cancel() is to communicate "I don't care about this stream anymore," so it's kind of rare you care about how well your not-caring went. But, we do need to pick one.

I think I have a slight preference for both reject, but could also go with one fulfills, second one rejects. Both fulfills seems bad.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/302#issuecomment-83484519

Received on Thursday, 19 March 2015 10:18:20 UTC