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

> Uhh.. consuming a promise is clearly a way to signal a direct interest in its results.

@benjamingr My library has no inherent interest in absorbing responsibility over whether what came before should be cancellable or not. Arguably, control to prevent cancellation is in many instances as powerful as cancellation itself, yet the disinterest pattern appears to avoid these instances rather than solve them. Not great for my library which will have no control over who's calling it.

> (quote from elsewhere) in bluebird semantics if you opt in to cancellation promise cancellation has disinterest semantics

I don't see anything opt-in about `disinterest` (an `interest` method would be opt-in). My library never opted in and still has to call it, it sounds, if it wants to avoid causing callers grief. If all it takes is for one person in a parade to call it a demonstration to make it a demonstration, then that's not opt-in.

> Your .catch(() => {}) example is a real use case though - typically in order to suppress unhandled rejections or to suppress errors explicitly. This of course can be dealt with either by calling .cancel on that promise immediately.

Look closely, and it's done on an internal *fork* of the promise chain, one that's never returned to the caller from this `queue` implementation. It exists to force separation between passed-in promise-returning functions which have nothing in common except only one is dealt with at a time (e.g. errors from one fork does not affect another, yet cancellation violates this separation?)

See https://github.com/whatwg/fetch/issues/27#issuecomment-87134228 for why this is harmful.

Other examples: For instance, here are two common patterns for injecting logging:

    return p.catch(e => {
        debug.log("This happened, fyi: " + e);
        throw e;
    });

or:

    p.catch(e => debug.log("This happened, fyi: " + e));
    return p;

Neither cause the promise chain to halt, but one of them causes cancellation to halt.

Lastly, for argument's sake, say I'm willing to call `cancel` in my implementation. When and how would I call it? Even after I've returned my promise, I may still be racing with some callers calling `then` on it, which I think means I risk accidentally cancelling the caller's previous operations immediately, right? Wouldn't that be a hard-to-find disaster?

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/27#issuecomment-177217620