I wish I knew about https://github.com/vsilaev/tascalate-concurrent 5 years ago. I think graphql-java and dataloader would be based on dependant promises in retrospect

One crazy idea would be to keep a "list of DataFetcher" root CFs some where - so that they could be directly cancelled - this would interrupt them (modulo what they are doing - eg IO is ok but tight CPU work would not be)

In theory some one could write a Instrumentation to do this by "instrumentating" each DF and looking at its returned value (CF or not)

Someone shared a similar concept for Spring for GraphQL. At this point, the overhead might be important for most cases and overall not really worth it?

Just spitballing :

There is a timeout mechanism on CompleteableFutures in Java 9 (which we are now on via min Java 11)

CompletableFuture<String> timedOut = asyncCF.orTimeout(5, TimeUnit.SECONDS);

This will throw a java.util.concurrent.TimeoutException if the upstream CF does not complete

This is run via an internal thread pool (of 1) in the JDK

        static final ScheduledThreadPoolExecutor delayer;
        static {
            (delayer = new ScheduledThreadPoolExecutor(
                1, new DaemonThreadFactory())).
                setRemoveOnCancelPolicy(true);
        }
       ...
                   whenComplete(new Canceller(Delayer.delay(new Timeout(this),
                                                     timeout, unit)));

However it does not interrupt the original work. Rather the "ticker" just returns an exception value for the CF - it does not stop any work that is happening - but one could imagine some how again instrumenting the DataFetcher CF so that it "cancels" on time out say just like we spoke about cancelling on some other signal (reactor back channel signal)

We found a way to solve this in Spring for GraphQL for reactive data fetchers: spring-projects/spring-graphql#1149

We are considering our options for non-reactive data fetchers here: spring-projects/spring-graphql#1153