Calling two mutations at the same time from different requests run serially

[gakio12]

I understand that the GraphQL spec calls for mutations called from the same request be executed serially, however currently two separate requests calling mutations at the same time are also run serially. How do we call resolve such that each request is treated as a different object and we can have two clients running mutations at the same time? I've tried creating a new Operations object prior to each resolve call, but it is still deferring execution of the second client's request until the first client's request is finished.

For example, when calling Client 1 and then calling Client 2 (3x) while Client 1 is executing:

Client 1

mutation a50 {
  sleep(time: 50)
}

Client 2

mutation a5 {
  sleep(time: 5)
}

Expected output (and output from the Graphene python library)

Starting to sleep for 50 seconds.
Starting to sleep for 5 seconds.
Done sleeping!
Starting to sleep for 5 seconds.
Done sleeping!
Starting to sleep for 5 seconds.
Done sleeping!
Done sleeping!

Actual output

<2020-12-17 16:37:12.660> Starting to sleep for 50 seconds.
<2020-12-17 16:38:02.660> Done sleeping!
<2020-12-17 16:38:02.661> Starting to sleep for 5 seconds.
<2020-12-17 16:38:07.661> Done sleeping!
<2020-12-17 16:38:07.661> Starting to sleep for 5 seconds.
<2020-12-17 16:38:12.662> Done sleeping!
<2020-12-17 16:38:12.662> Starting to sleep for 5 seconds.
<2020-12-17 16:38:17.662> Done sleeping!

[gakio12]

I want to point out that queries don't behave like this and each request is properly started in a separate thread from the transport mechanism. It is definitely the std::launch::deferred for mutations that is causing the entire endpoint to execute all clients' mutations in serial.

[wravery]

Got it. There's a workaround you could use which is to wrap your own calls to resolve in std::async(std::launch::async, ...), but the real fix should be to stop overriding the launch variable used internally to call std::async from Request::resolve and only override the parameter passed to the OperationDefinitionVisitor constructor so it runs serially but on a top level future which is still using the parameter that was passed in.