Ensure field errors are populated in FetchedResult#2520
Merged
andimarek merged 4 commits intographql-java:masterfrom Aug 27, 2021
Merged
Ensure field errors are populated in FetchedResult#2520andimarek merged 4 commits intographql-java:masterfrom
andimarek merged 4 commits intographql-java:masterfrom
Conversation
added 3 commits
August 20, 2021 10:11
…tion `beginFieldComplete` is called Currently if a DataFetcher raises an exception in any way, the FetchedValue given in the instrumentation does not contain any errors information. The only place errors are available are on the ExecutionContext within a list, which is not ideal to determine if the current field has an error. This change ensures that FetchedValue contains errors if any was raised during `DataFetcher.get`.
Member
|
Thanks for this PR. I think this is a more elegant way for exceptions errors . The old code looks a bit crusty and I think its come from a time when graphql-java was "synchronous" and we didn't have I think this is a valuable editions for Instrumentations that want to get all the returned values including errors. ps. if we had out time again we would have made DataFetcher have this signature and then we would garuntee that you should not come back out from a fetch with anything else but data, errors or both. But anyway I disgress |
bbakerman
approved these changes
Aug 25, 2021
Contributor
Author
|
Thanks @bbakerman! |
andimarek
approved these changes
Aug 27, 2021
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently if a DataFetcher raises an exception in any way, the
FetchedValuegiven in the instrumentationbeginFieldCompletemethod does not contain any errors information. The only place errors are available are on theExecutionContextwithin a list, which is not ideal to determine if the current field has an error. This change ensures that FetchedValue contains errors if any was raised duringDataFetcher.get.The solution simply allows the
unboxPossibleDataFetcherResultto hit theresult instanceof DataFetcherResultcase which properly passes through errors in the ExecutionContext and in theFetchedResultitself. Since I'm not super familiar with the code base, this implementation has to cast to typeT, which seems safe since the method was returning null in the first place but would defer to your suggestions to change.Another possible solution is to expose a
containsErrorPathmethod onExecutionContextas the context maintains aSet<ResultPath> errorPathswhich could be used to look up the current ResultPath in the instrumentation to see if it's an error. However, having the error directly on theFetchedValueseems to make more sense.