Has anyone encountered an issue with Lacinia where if you have arguments to a field, the resolver is asynchronous, and the parent resolver is asynchronous, the parent and child execute in parallel? I have a child resolver that depends on the parent to pass down context values, but when the child is asynchronous and has arguments the execution order is not what I expect it to be.

I’m thinking maybe this is part of the GraphQL spec, but I haven’t been able to track it down.

Normally it waits for the parent to resolve before resolving the child even when both are async, but adding arguments to the field resolver causes that to change.

graphql lets resolvers work in parallel

i think its part of the spec that order of execution for queries is undefined

gotcha makes sense, thanks

This is the part of the Lacinia docs I read that I thought suggested it would happen in the order I stated above

https://lacinia.readthedocs.io/en/latest/resolve/selections.html

In execution order, resolution occurs top to bottom, so the hero selection occurs first, then (potentially in parallel) friends, home_planet, and (hero) name. These last two are leaf nodes, because they are scalar values. The list of characters (from the friends field) then has its name field selected. The result map then constructs from bottom to top.

is there a key in the context (or maybe something in the selection protocols) that allows a resolver to find out what query/mutation/subscription it was invoked from?

preferably something that is part of the public api.