This commit adds a new web interceptor that can be configured with a
specific duration. If the response is not produced within this timeline,
the interceptor sends a HTTP error status to the client (by default,
"REQUEST TIMEOUT" but this can be configured) and sends a CANCEL signal
upstream.
This CANCEL signal flows up to controller methods and maually registered
data fetchers, if they have a reactive return type. Processing will be
automatically aborted.
For other types of date fetchers, applications can retrieve a publisher
from the GraphQL context and get notified of cancellations.
Closes gh-450
Prior to this commit, a WebSocket/SSE client disconnecting from the data
stream would cause a CANCEL signal to be sent to upstream publishers.
This signal would flow from the transport layer up to the
`ExecutionGraphQlService`. Because the `GraphQL` engine itself relies on
`CompletableFuture`, the CANCEL signal would not flow through and
reactive data fetchers would not receive it. This means that costly
reactive operations would not be cancelled and this could cause write
failures as publishers would still produce values.
This commit adds at the service level a Reactor `Sink` to the
`GraphQLContext` that can be picked up by the
`ContextDataFetcherDecorator` when decorating reactive data fetchers.
This allows us to manually cancel publishers when the CANCEL signal is
received at the transport level.
Fixes gh-1149
Reflect jakarta classifiers for Querydsl annotation processing. Also, update to Java 22+ conventions requiring annotation processor paths instead of relying on annotation processors present in dependencies.
Closes gh-1121
This commit concludes the support for the "GraphQL over HTTP" spec, with
both clients and servers complying with the expected behavior for the
"application/graphql-response+json" response media type.
Closes gh-1117
This commit renames and changes the behavior of the configuration option
on `GraphQlHttpHandler` implementations. The
`setHttpOkOnValidationErrors` option is `false` by default and is
introduced as a deprecated method right away. Our goal here is to fade
out this option as soon as possible the traditional behavior for
"application/graphql-response+json" media types.
See gh-1117
This commit adapts the GraphQlClient HTTP transports (async and sync) to
accept 4xx responses if the response content type is
"application/graphql-response+json".
This allows the client to support the "GraphQL over HTTP" specification.
This commit adds a new test suite to check compatibility against this
spec.
See gh-1117
This should have been removed when we upgraded to
"io.spring.develocity.conventions:0.0.22".
I suspect this is the reason we are not getting build scan URLs in
GitHub action runs anymore.
Prior to this commit, the `ExecutionGraphQlService` would throw
`GrahphQLException` instances if errors happen early in the process, for
example in some cases of document parsing/validation.
Such exception would be thrown directly and not reflected in the GraphQL
response if those are `GraphQLError`.
This commit ensures that a fallback GraphQL response is created in this
case and that it contains the relevant `GraphQLError` information.
Fixes gh-1118
Prior to this commit, the `GraphQlHttpHandler` implementations for MVC
and WebFlux would support the HTTP transport protocol for servers.
They would align with the well-known GraphQL behavior, using HTTP as a
transport and always using HTTP 200 OK as response status.
The new GraphQL over HTTP specification changes that, and requires
servers to respond with HTTP 4xx/5xx statuses when an error occurs
before the GraphQL request execution: for example, if the JSON document
cannot be parsed, or the GraphQL document is invalid.
This commit introduces a new "standard mode" option on HTTP transports
to follow this new requirement. Because this is a breaking change for
GraphQL clients, this mode is opt-in only for now.
See gh-1117
