Re: [fetch] Aborting a fetch (#27)

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