thanks for the reply
I actually started to think about this because of the DataLoaderDispatcherInstrumentation and how the FieldLevelTrackingApproach determines when all fields in a certain level were dispatched.

Can I ask a reverse question - what would you do if you know if a certain set of fields (or tree branches) as complete?

i have a level of indirection on top of the GraphQL API that concurrently executes n ExecutionInput
so i was able to create my own Instrumentation mostly based on DataLoaderDispatcherInstrumentation to be applied not by operation but for all operations.

However i started to think about some use cases where dispatching a dataLoader by level could not cover some use cases like this.

If we execute the dataLoader by level, we would be fetching astronaut field 2 times, instead of one
however if we try to exhaust all synchronous processing we could end in the desired scenario which is

First ExecutionInput having astronaut field of first query dispatched
Second ExecutionInput having nasa completed (not completable future) his children astronaut dispatched (completable future), address and his children (street, zipCode) completed, phoneNumber completed

Remember that DataLoaders are stateful objects. They are intended to be used per request... If you share them across requests you will get funk results much like you describe.

i have a level of indirection on top of the GraphQL API that concurrently executes n ExecutionInput

I this N queries for 1 http request / one user say?

Is it that you want to execute a astronaut once of cache values form it so that previous calls will satify later ones? Because DataLoader has a caching layer you can use?

It will be the same request, we have a GraphQL server capable of dispatching batched GraphQL operations in a concurrent manner

[
  {"query": "...", "operationName": "", "variables": {} },
  {"query": "...", "operationName": "", "variables":  {}}
]

cache would definitely help but imagine these 2 queries

"query { astronaut(id: 1) { id name } }",
"query { nasa { astronaut(id: 2) { id name } address { street zipCode } phoneNumber } }"

given the fact that input is different, for the second request for astronaut (id:2), there won't be an entry in the cache

Maybe what you could do it is put a wrapper on the DataLoaderRegistries and then ONLY dispatch them when all N of them per request have asked to be dispatched.

The instrumentation per ExecutionInput ultimately calls dataLoaderRegistry.dispatchAll() to say do the work.

If you have N DataLoaderRegistrys then can you created a CombinedDataLoaderRegistry that only really does the dispatched calls when the N underlying registries have all reported in? This is of course very stateful because once it reports in, you need to decrement some N base counter but if it reports in again, you need to deprecate a different counter. It might prove too hard to know what level you are on.

One of the problems of course here with your batching is the problem if what is fastest.

You can MAXIMISE your batching so that you calls to the astronaut data service does the minimal number of calls BUT you may well be causing them to "wait" longer for all N batches to synchronise such that the total time is worse. If MAY prove that you should have let them make their calls with less optimal batching because it would have been faster to let them go earlier.

There is no clear answer on this of course. Batching minimises the number of data loading calls but may expand the total time to getting all the data.

This sounds really exciting - we tracked levels as a strategy on when best to dispatch. If you have a better way (exhaust all synchronous fields say) then we would be interested

we also tested the use case that is highlighted here
#1198

the only thing that we needed to do is to decorate a DataLoader registry to have access to the DataLoader's CacheMap to have access to the futures

we are happy to open a discussion in the dataloader project to possibly make the DataLoader cacheMap visible

the only thing that we needed to do is to decorate a DataLoader registry to have access to the DataLoader's CacheMap to have access to the futures

So you idea here is that multiple dataloaders calls would then make entries into the "list" of things that must complete to be marked as dispatchable??

While better than what graphql-java has today (we track field dispatches on levels boundaries) it still has a challenge of optimal batching windows.

Imagine a DL call chain that is "get invoice" followed by a "get user" (for that invoice)

  CompleteableFuture<Invoice> cf1 = invoiceDL.loadKey(invoiceId)
  CompleteableFuture<User> cf2 = cf1.thenApply( invoice -> userDL.loadKey(invoice.approverId));
  return cf2.thenApply( user -> combineIvoiceAndUser(invoice,user));

In theory if you can reach in and know about the outstanding dataloader CompleteableFutures (and when they complete) then you can call dispatch again once the invoice call has completed. (albeit you need to be able to change the cached CF to create a "happens before" relationship on cf1 to ensure your dispatch happens BEFORE cf1 code runs again.)

However is it a good time to dispatch? Maybe some other part of the query is loading users as well? Maybe they should be folded into the "batch window" so that 4 outstanding user calls get dispatched as a "batch" but a naive impl may dispatch them in batches of 1 depending on how the calls happen.

This is the biggest problem I see with multiple dataloader calls - how to know when the best time to dispatch is that maximizes your batch window.

Now maybe I am overthinking it and if we consider the primary data loader calls (which can be optimised into batch windows via graphql boundaries (field levels or exhausted sync field calls) to be the most important in terms of batch window.

However is it a good time to dispatch? Maybe some other part of the query is loading users as well? Maybe they should be folded into the "batch window" so that 4 outstanding user calls get dispatched as a "batch" but a naive impl may dispatch them in batches of 1 depending on how the calls happen.

In theory with the AST we can know which fields have a dataLoader associated with, so we could define the batching window programatically.

This is exactly why we were thinking about the other strategy, which is exhaust the synchronous execution, with this we will be dispatching exactly where is needed.

It kinds of simulates what the event loop does in graphql-js

Consider this diagram, (better representation of the original one)

query Q1 {
    astronaut(id: 1) { # async
        id
        name
        missions { # async
            id
            designation
        }
    }
}

query Q2 {
    nasa { #sync
        astronaut(id: 2) { # async
            id
            name
            missions { # async
                id
                designation
            }
        }
        address { # sync
            street
            zipCode
        }
        phoneNumber
    }
}

With this instrumentation we would be batching the transaction to get

1. Astronaut 1 and Astronaut 2
2. Missions of Astronaut 1 and Missions of Astronaut 2

in graphql-kotlin we have created a custom instrumentation that will dispatch dataloaders when the synchronous execution of a graphql operation is exhausted --
https://opensource.expediagroup.com/graphql-kotlin/docs/server/data-loader/data-loader-instrumentation/

Synchronous execution is considered exhausted (or completed) when all currently processed data fetchers were either resolved to a scalar or a future promise.

through hooks and a data structure to keep state of fields we where able to do it.
you can use this instrumentation in any app using that uses graphql java.

i have pending making this contribution to graphql java, but i haven't had the time to do it.

we have also created an extension function to solve the problem of nested dataloaders
https://opensource.expediagroup.com/graphql-kotlin/docs/server/data-loader/data-loader-instrumentation/#dispatchifneeded

thanks for the explanation!