- From: Martin Thomson <notifications@github.com>
- Date: Fri, 27 Mar 2015 17:53:13 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/27/87134228@github.com>
Now that I've properly considered the upstream propagation of cancellations, I think that I've concluded that it's a real hazard.
If the intent of the sequence is to produce just the final product of a promise chain, then that is the only case where this is OK. However, a promise chain can frequently have side effects that are important to the functioning of a program. Pushing a cancellation upstream risks a downstream consumer of a promise cancelling actions, often unbeknownst to them, in code for that they don't necessarily know the structure of.
Consider:
```js
Obj.prototype.doSomethingInnocuous = function() {
if (this.alreadyRun) { return Promise.resolve(); }
return innocuousActivity(t).then(() => { this.alreadyRun = true; });
}
var commitFetch;
obj.doSomethingInnocuous()
.then(() => commitFetch = fetch(commitUrl, {method: 'POST'}))
.then(showResult);
cancelButton.onclick = e => commitFetch.abort();
```
Here, you might admit the possibility that `innocuousActivity()` is cancellable. But the code that calls it doesn't expect it to be cancelled. Maybe the ability to cancel this operation wasn't even added until a recent update. But a failure there leaves means that the activity is run multiple times if ever it were cancelled. That might be OK, but you don't know if that is true; certainly steps were taken to ensure that it wasn't called twice.
Obviously you can structure the code functions so that important cancellable activities are defended by having unreachable dependencies:
```js
var p = importantThing();
p.then(() => {}); // prevent a cancellation on timeout()
return p.then(() => {});
```
Or something like that, but that sort of defensive programming is extremely non-obvious. I think that would make cancellation virtually unusable by virtue of creating a strong disincentive to use it for fear of the potential for collateral damage.
---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/27#issuecomment-87134228
Received on Saturday, 28 March 2015 00:53:35 UTC