Don't run the rejection path on cancelled promises

[tokland]

Long-standing async tasks libraries like fluture or fun-task don't run the reject callback on cancellation. If possible, I think it would be great to follow the same path for real-cancellable-promise.

It may look counterintuitive at first, but when you work with these libraries, you realize that it makes a lot of sense. The idea is that it was the consumer who canceled the operation, so it's redundant that the consumer should also get a rejection. The whole argument by the author or fluture, here.

I think that the pattern we need to identify cancellation vs "normal exception" signals that something is off. Or the gymnastics with rejectFn in delay.

I am aware that the scenario for real-cancellable-promise is a bit different, as it works with Promise-like objects (thenables), so code like await cancellablePromise would hang forever when canceled, right? In any case, it seems to me that one should always write await capture(cancellablePromise) anyway, and the wrapper could then capture the cancellation. I am not familiar with the internals of the library, so there may be extra problems for this to be implemented. Something to investigate: fluture-js/Fluture#216 (comment).

In any case, thank you for the project and especially for buildCancellablePromise! I used the same pattern to write an equivalent wrapper for fluture, and it works nicely.

[srmagura]

Nice analysis! 😁

Personally, I do not like promises that neither resolve nor reject. It can cause bugs if you write code like this:

setLoading(true);
await cancelableOperation();
setLoading(false);

Your loading spinner would get shown forever if the operation gets canceled. 😉 I think this example shows that, in some cases, the code that triggered the asynchronous operation also needs a way to be notified if the operation is canceled.

There also seems to be a fundamental difference between native promises (which CancellablePromise emulates) and the "futures" returned by Fluture. This is explain one of the comments you linked: fluture-js/Fluture#216 (comment).

As another data point, in C#, if a Task is canceled, it throws a TaskCanceledException. This is essentially the same as what real-cancellable-promise does.

[tokland]

Definitely, it'd be a problem when awaiting raw canceled promises outside buildCancellablePromise(). I'd have to do some more testing over the unicast/multicast thing to be sure, but basically, I wanted to check if you were ok or not conceptually with cancellations rejecting promises (you are). Good luck with the project, I'll be using it!

[srmagura]

If it wasn't clear — yes I am OK with cancellations rejecting the promise. Thanks for your interest in the project!

[tokland]

Sure! :)