Cancellation signal is not propagated from transports to reactive controller methods #1149
Assignees
Milestone
Comments
bclozel
added
in: core
This was referenced Mar 11, 2025
bclozel
added a commit
that referenced
this issue
Mar 28, 2025
As of gh-1149, CANCEL signals are propagated from the transport request up to reactive `DataFetcher`s. This efficiently cancels processing and avoids spending resources when execution results won't be sent to the client. Prior to this commit, this would have no effect on non-reactive `DataFetcher`s because they would still be executed. While we cannot consistently cancel ongoing blocking operations, we can avoid further processing and other `DataFetcher`s from being called by returning an error result instead of the original result. This commit updates the `ContextDataFetcherDecorator` to detect if the request has been cancelled and return early a data fetcher result with a `AbortExecutionException` error instead of the original result. Closes gh-1153
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As raised in #450, cancel signals are not propagated from the transport layer, through the
ExecutionGraphQlService, up to the data fetchers provided by the application. This mostly applies to controller handlers with aPublisher-like return type and subscriptions in general. This is due to a well-knownCompletableFuturebehavior.We can work around this limitation by propagating this signal out of band through a
Sinkin the GraphQL context.The text was updated successfully, but these errors were encountered: