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

> Unless I'm understanding the spec wrong, I think the problem is that waitingPromise has already resolved, but it's resolved with a promise, so waitingPromise hasn't yet settled. Allowing a promise that has resolved but not settled to cancel could solve this, but that might have a greater impact elsewhere.

No, not according to the [A+ spec](https://promisesaplus.com/). It specifies how to handle a promise of the [same implementation](https://promisesaplus.com/#point-49) and a promise of a [different implementation](https://promisesaplus.com/#point-56). In the first case it adopts the state, which is done to reduce the memory footprint of promises (see [this discussion thread](https://github.com/promises-aplus/promises-spec/issues/179)). A CancellablePromise can chose not to do the optimization of adopting the state, but always use the [2.3.3](https://promisesaplus.com/#point-53) algorithm to get around this. It also won't have the memory leak issue, since a chain of never resolving promises can be cancelled from the outside, which will unravel the chain. [My implementation](https://github.com/mariusGundersen/ignorablePromise/blob/master/lib/core.js) does this. 

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