Description
Library Version
8.2.1
Describe the bug
We tried to enable APQ in spring server, which according to the documentation requires only setting automaticPersistedQueries.enabled: true
, but unfortunately the APQ flow doesn't work as expected because the initial GET call fail in GraphQLServer with bad request without a body (I'd expect a PersistedQueryNotFound error be available in the payload, for eg). The AutomaticPersistedQueriesProvider is not even executed.
The request fails because the parseRequest returns null (no query parameter available):
open suspend fun execute(
request: Request
): GraphQLServerResponse? =
coroutineScope {
requestParser.parseRequest(request)?.let { graphQLRequest ->
val graphQLContext = contextFactory.generateContext(request)
val customCoroutineContext = (graphQLContext.get<CoroutineContext>() ?: EmptyCoroutineContext)
val graphQLExecutionScope = CoroutineScope(
coroutineContext + customCoroutineContext + SupervisorJob()
)
val graphQLContextWithCoroutineScope = graphQLContext + mapOf(
CoroutineScope::class to graphQLExecutionScope
)
requestHandler.executeRequest(graphQLRequest, graphQLContextWithCoroutineScope)
}
}
and therefore the router returns bad request here (GraphQLRoutesConfiguration):
@Bean
fun graphQLRoutes() = coRouter {
val isEndpointRequest = POST(config.endpoint) or GET(config.endpoint)
val isNotWebSocketRequest = headers { isWebSocketHeaders(it) }.not()
(isEndpointRequest and isNotWebSocketRequest).invoke { serverRequest ->
try {
val graphQLResponse = graphQLServer.execute(serverRequest)
val acceptMediaType = serverRequest
.headers()
.accept()
.find { it != MediaType.ALL && it.includes(MediaType.APPLICATION_GRAPHQL_RESPONSE) }
?.let { MediaType.APPLICATION_GRAPHQL_RESPONSE }
?: MediaType.APPLICATION_JSON
if (graphQLResponse != null) {
ok().contentType(acceptMediaType).bodyValueAndAwait(graphQLResponse)
} else {
badRequest().buildAndAwait()
}
} catch (e: Exception) {
badRequest().buildAndAwait()
}
}
}
To Reproduce
We first tried it with Apollo Client and our own requests and saw the router not being able to resolve the request with 400s, and then we tried to reproduce it with simple examples from Apollo as described below:
1st GET request without query returns 400:
curl --get http://localhost:4000/graphql \
--header 'content-type: application/json' \
--data-urlencode 'extensions={"persistedQuery":{"version":1,"sha256Hash":"ecf4edb46db40b5132295c0291d62fb65d6759a9eedfa4d5d612dd5ec54a6b38"}}'
2nd GET request with query returns 200:
curl --get http://localhost:4000/graphql \
--header 'content-type: application/json' \
--data-urlencode 'query={__typename}' \
--data-urlencode 'extensions={"persistedQuery":{"version":1,"sha256Hash":"ecf4edb46db40b5132295c0291d62fb65d6759a9eedfa4d5d612dd5ec54a6b38"}}'
Send another GET request without the query and the cache is still not checked and we still receive 400:
curl --get http://localhost:4000/graphql \
--header 'content-type: application/json' \
--data-urlencode 'extensions={"persistedQuery":{"version":1,"sha256Hash":"ecf4edb46db40b5132295c0291d62fb65d6759a9eedfa4d5d612dd5ec54a6b38"}}'
Expected behavior
The first call should not fail with bad request, and it should be able to resolve from cache after the result is properly cached.
Also, from the client implementation that's how it's supposed work (first request without a "query" parameter):