ChatGPT is telling me that cancellation does not propagate across orElseGet or thenCompose operators, but that doesn't seem right and I can't find this in the docs at https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html. May need a test somehow confirming cancel after this orElseGet does actually prevent the delayed call from being invoked. If it doesn't work, I can make some suggestions I think.

I think this works fine because the returned future is permitFuture which is thenComposed with the future from here. Added a test that confirms.

My concern is that ChatGPT says that a cancel of the outer future does not propagate the cancel to the thenComposed future. Not sure I believe it because I haven't tested, but it does concern me. I would have to test Java behavior of cancel when the thenCompose has already run to create a new future. I may set aside some time to do this.

But I fear reading https://stackoverflow.com/questions/25417881/canceling-a-completablefuture-chain and poking around, there may need to be some other mechanism to make sure the outer completable future cancel propagates to cancelling the delayed executor. I couldn't tell if the test was doing that. I wouldn't be surprised if cancel is not hierarchical.

Canceling a completable future is not a good way to tell the producer the result is no longer needed, it is to tell the consumer.

https://stackoverflow.com/questions/23320407/how-to-cancel-java-8-completable-future

So the standard library would use Future for this like here https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ScheduledFuture.html. The other option is to return a special interface like SlotSupplierFuture interface that implements the CompletableFuture interface and another different "cancel" method that actually does what you want

I've dealt with this by returning future and using an anonymous class in the one spot (two counting test code) I actually need another stage. It works fine since the "callback" (incrementing the counter in the tracking slot supplier) only ever needs to be called if get is actually invoked, and it always is anyway.

Can there be an example of how a user who is implementing a slot supplier can react to reservation cancellation? Or maybe that one already is. My fear is they'll use naive futures and it'll hang shutdown. Which of course is their fault, I just want to make sure we clarify (maybe via test but for sure via docs) that if they want to handle cancellation of reserve slot, they may need provide their own future implementation that reacts to the cancel call properly.

I think the existing docstring is reasonably clear on that front. I could add a warning about using CompletableFuture specifically, and if they do that they maybe want to be aware of how that can go wrong (which wasn't obvious to me at least so maybe that's a good idea) but I suppose otherwise it's like any other Future returning Java API

I suppose otherwise it's like any other Future returning Java API

Yup but still a bit confusing because most don't manually implement cancel. I propose we alter the javadoc to change from:

These futures may be cancelled if the worker is shutting down or otherwise abandons the reservation. This can cause an {@link InterruptedException} to be thrown, in the thread running your implementation. You may want to catch it to perform any necessary cleanup, and then you should rethrow the exception.

To:

These futures may get cancel invoked on them if the worker is shutting down or otherwise abandons the reservation. Users need to make sure they handle cancel on the resulting future. By default in Java, futures created by users or composed from other futures will not properly propagate cancel so users need to make sure this is handled properly.

Can still add note about the exception if we do handle that special. Regardless, non-blocking.

These futures may be cancelled if the worker is shutting down or otherwise abandons the

You are aware CompletableFuture cancellation does not propagate upstream correct?