Update default exception handler to use SimpleKotlinGraphQLError #369
Conversation
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
By default, our default exception handler was wrapping all the runtime exceptions in `graphql-java` `ExceptionWhileDataFetching` GraphQLError. Since this default GraphQL error exposes `exception` field it was also getting serialized in the response. While this is was still valid GraphQL response, per [spec](https://graphql.github.io/graphql-spec/June2018/#sec-Errors) `exception` field is not part of the defined error fields and instead should be included in the error `extensions` entry field instead (if at all). Note: the above serialization issue could also be solved by using `graphql-java` `ExecutionResult#toSpecification` method to generate final results but that would also imply that we would need to return `Map` instead of a `GraphQLResponse`.
Codecov Report
@@ Coverage Diff @@
## master #369 +/- ##
=========================================
Coverage 94.46% 94.46%
Complexity 323 323
=========================================
Files 97 97
Lines 1139 1139
Branches 204 204
=========================================
Hits 1076 1076
Misses 22 22
Partials 41 41
Continue to review full report at Codecov.
|
smyrick
approved these changes
Sep 23, 2019
smyrick
added
changes: patch
dariuszkuc
added a commit
to dariuszkuc/graphql-kotlin
that referenced
this pull request
Aug 5, 2022
…ediaGroup#369) By default, our default exception handler was wrapping all the runtime exceptions in `graphql-java` `ExceptionWhileDataFetching` GraphQLError. Since this default GraphQL error exposes `exception` field it was also getting serialized in the response. While this is was still valid GraphQL response, per [spec](https://graphql.github.io/graphql-spec/June2018/#sec-Errors) `exception` field is not part of the defined error fields and instead should be included in the error `extensions` entry field instead (if at all). Note: the above serialization issue could also be solved by using `graphql-java` `ExecutionResult#toSpecification` method to generate final results but that would also imply that we would need to return `Map` instead of a `GraphQLResponse`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
📝 Description
By default, our default exception handler was wrapping all the runtime exceptions in
graphql-javaExceptionWhileDataFetchingGraphQLError. Since this default GraphQL error exposesexceptionfield it was also getting serialized in the response. While this is was still valid GraphQL response, per specexceptionfield is not part of the defined error fields and instead should be included in the errorextensionsentry field instead (if at all).Note: the above serialization issue could also be solved by using
graphql-javaExecutionResult#toSpecificationmethod to generate final results but that would also imply that we would need to returnMapinstead of aGraphQLResponse.🔗 Related Issues
#366 - [question] how to disable stacktrace in error responses