Add support for removing cancelled bluebird3 promises from the cache.

[Page-]

When a bluebird3 promise is cancelled it doesn't call any success/failure handles which means that it appears to be permanently waiting in terms of the cache and will be given out to every subsequent call.
This is a problem as when you try to subscribe to the returned, cancelled, promise it rejects with a CancellationError so we end up with a poisoned cache. This PR checks if the promise can attach cancellation handlers and if so we attach the onFailure handler to clean up in case of cancellation

[medikoo]

For some reason tests failed in some engines on Windows.

Maybe it's issue of some race condition in setTimeout handling (I would increase success resolution timeout to 500)

[medikoo]

I think it'll be nicer to rely on public API, so promise.finally (that way we'll also support also any other implementation that do cancellation)>

For that we can add promise.finally(function () { nextTick(onFailure); }) to then mode.

[Page-]

Yeah, that's much better - for some reason I thought finally didn't get called on cancel

[Page-]

The lint is now failing due to an update in https://github.com/medikoo/eslint-config-medikoo - how would you like the lint cases fixed?

[medikoo]

The lint is now failing due to an update in https://github.com/medikoo/eslint-config-medikoo - how would you like the lint cases fixed?

I've fixed this in master. Issue was related to recent eslint upgrade (v4 -> v5). Therefore merge, and lint should be ok

[Page-]

I picked up the master changes and all the tests look good now

[medikoo]

Thank you, published with v0.4.13

[Page-]

Awesome, thanks!

[petrosagg]

@Page- @medikoo won't this always call onFailure and always remove it from the cache? It looks like .finally is called regardless http://bluebirdjs.com/docs/api/finally.html

[medikoo]

It will, but first what's attached is callback to then, and that one will be first invoked in success case. Fact that nextTickFailure will be invoked afterwards in all cases does no harm, it'll just exit here:

memoizee/ext/promise.js

Line 58 in 2b1f941

if (!waiting[id]) return; // Deleted from cache (or succeed in case of finally)

Still, even If there's some promise library which in given scenario:

promise.then(callback1)
promise.finally(callback2)

will call callback2 before callback1, it'll crash with meaningful error here:

memoizee/ext/promise.js

Lines 44 to 49 in 2b1f941

	throw new Error(
	"Memoizee error: Detected unordered then|done & finally resolution, which " +
	"in turn makes proper detection of success/failure impossible (when in " +
	"'done:finally' mode)\n" +
	"Consider to rely on 'then' or 'done' mode instead."
	);

So situation will be properly exposed

[petrosagg]

I see, thanks for the explanation.

The only case I see that could potentially produce a false positive is if one of nextTick's implementations doesn't guarantee in-order execution of the scheduled functions.

[medikoo]

The only case I see that could potentially produce a false positive is if one of nextTick's implementations doesn't guarantee in-order execution of the scheduled functions.

I'm pretty sure order is guaranteed in all of them, otherwise there will be dragons :)