[antjanus]

This is great!

I actually had to write my way around non-cancellable promises quite a few times and my situation mirrors yours though mostly on the client:

I have a search page that updates results every time a new filter is updated (imagine you select a new tag to filter by, or narrow down the search somehow). This can be done faster than responses come back and can create a huge mess because some responses can come back faster than others.

This creates uncertainty in terms of what should be on the page. A few lines of code and it's fixed but the cool thing is that I get to throw away results that I don't care about and not process them (expensive-ish action).

This kind of situation happens somewhat often because a user can quickly navigate around, fire off a ton of requests and only really cares about the last one in the queue.

I haven't worked my way around it on a global scale which means that there could be a ton of requests being processed and thrown away right after for no good reason.

[Mitranim]

Glad you understand the problem. This is what futures are good for. Write an XMLHttpRequest adapter that returns a future, have an easy time composing or aborting operations.