Skip to content

fix: stop swallowing coroutine cancellation in GraphQLRequestHandler - #2223

Open
ujjawal-yadav wants to merge 1 commit into
ExpediaGroup:masterfrom
ujjawal-yadav:fix/request-handler-cancellation
Open

ujjawal-yadav wants to merge 1 commit into
ExpediaGroup:masterfrom
ujjawal-yadav:fix/request-handler-cancellation

Conversation

@ujjawal-yadav

Copy link
Copy Markdown

📝 Description

GraphQLRequestHandler.execute catches Exception and turns it into an error response. On the JVM, CancellationException is an Exception, so when the coroutine running the request is cancelled (for example by a timeout, or a client disconnect that cancels the request), the handler treats the cancellation as an ordinary execution error and keeps going. Batches that contain a mutation run sequentially, so the remaining operations still execute after the request has been cancelled.

The catch block now calls currentCoroutineContext().ensureActive(), so the handler rethrows only when its own coroutine has been cancelled. Every other exception, including a CancellationException from a cancelled future while the request is still active, is still returned as a GraphQL error, as before.

The new test cancels a batch of two mutations while the first is still running. On master the second mutation executes; with this change it doesn't.

🔗 Related Issues

Related to #1920. The original context-factory report no longer reproduces on master; this fixes the cancellation case found in the same thread: #1920 (comment)

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant