You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since Spring MVC supports async responses, and graphql-java itself works asynchronously, we can safely go fully async and bring the default MVC executor in line with the WebFlux one.
The only downside is that it breaks existing tests using MockMvc. The options are to use asyncDispatch or use blocking execution in tests.
To restore the old blocking behavior, it is enough to add graphql.spqr.http.mvc.executor=blocking to application.properties. This is what we do in our own tests.
The affect of this is the same is as if new DefaultGraphQLExecutor(...).blocking() was registered as a bean, e.g.:
Since Spring MVC supports async responses, and graphql-java itself works asynchronously, we can safely go fully async and bring the default MVC executor in line with the WebFlux one.
The only downside is that it breaks existing tests using
MockMvc
. The options are to useasyncDispatch
or use blocking execution in tests.To restore the old blocking behavior, it is enough to add
graphql.spqr.http.mvc.executor=blocking
toapplication.properties
. This is what we do in our own tests.The affect of this is the same is as if
new DefaultGraphQLExecutor(...).blocking()
was registered as a bean, e.g.:The text was updated successfully, but these errors were encountered: