Skip to content

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.

5 participants