Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding support for making the exception handlers async #2371

Merged
merged 6 commits into from
Jun 23, 2021

Conversation

bbakerman
Copy link
Member

This makes the data fetching exception handlers async.

The old method is left in place for backwards compatibiility reasons but the new async version is the one called.

It will delegate back to the old sync method.

New implementations can use proper async processing in making fetching errros

*
* @return a result that can contain custom formatted {@link graphql.GraphQLError}s
*/
default CompletionStage<DataFetcherExceptionHandlerResult> handleException(DataFetcherExceptionHandlerParameters handlerParameters) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we use CompletableFuture everywhere, no?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed

default CompletionStage<DataFetcherExceptionHandlerResult> handleException(DataFetcherExceptionHandlerParameters handlerParameters) {
DataFetcherExceptionHandlerResult result = onException(handlerParameters);
return CompletableFuture.completedFuture(result);
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The consuming code only calls this method. It delegates back to the old sync method. So any current implementations will continue to work.

Later at some point we can remove the deprecated version for a breaking change

}
})
.thenCompose(errorOrValue -> errorOrValue)
.thenApply(result -> unboxPossibleDataFetcherResult(executionContext, parameters, result));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need to flat map the above CF<T> back to a

@bbakerman
Copy link
Member Author

bbakerman commented Jun 4, 2021 via email

@bbakerman
Copy link
Member Author

Part of this PR is related to #2369 and unrolls the work of #2008

The contention we have identified is on "read" (the normal case) versus the exceptional case of errors.

Copy link

@rstoyanchev rstoyanchev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM from an API perspective.

@dfa1
Copy link
Contributor

dfa1 commented Jun 11, 2021

@bbakerman would it be possible to merge this PR? or at least the commit e7f5a91 ?

@bbakerman bbakerman merged commit 89f328c into master Jun 23, 2021
@bbakerman
Copy link
Member Author

@dfa1 - done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants