- 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