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

Improve default InvalidNullError handling #5257

Merged
merged 1 commit into from
Feb 28, 2025

Conversation

swalkinshaw
Copy link
Collaborator

Closes #5239

InvalidNullError was modeled as a RuntimeTypeError but also implemented to_h to act like an ExecutionError. It was a strange hybrid which made it harder for applications to change how the errors were handled.

It also caused limitations such as not being easy to add extensions or path to the error in the response.

This changes InvalidNullError to inherit from the base GraphQL::Error instead of RuntimeTypeError. Instead of adding the instance of InvalidNullError directly to context.errors, the default implementation is changed to create a new ExecutionError instead.

This provides a simpler middle ground where applications can still choose to handle InvalidNullError exceptions differently (such as reporting them to their exception handler app) but keep the proper spec compliant field error response.

Note: assuming this solution is good, I'll rebase this after #5256

end

# @deprecated always false
def parent_error?
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice cleanup

`InvalidNullError` was modeled as a `RuntimeTypeError` but also
implemented `to_h` to act like an `ExecutionError`. It was a strange
hybrid which made it harder for applications to change how the errors
were handled.

It also caused limitations such as not being easy to add `extensions` or
`path` to the error in the response.

This changes `InvalidNullError` to inherit from the base
`GraphQL::Error` instead of `RuntimeTypeError`. Instead of adding the
instance of `InvalidNullError` directly to `context.errors`, the default
implementation is changed to create a new `ExecutionError` instead.

This provides a simpler middle ground where applications can still
choose to handle `InvalidNullError` exceptions differently (such as
reporting them to their exception handler app) but keep the proper spec
compliant field error response.
@swalkinshaw swalkinshaw force-pushed the fix-invalid-null-error-handling branch from dac5d2a to b74c41b Compare February 27, 2025 16:43
@rmosolgo
Copy link
Owner

Thanks for this improvement!

@rmosolgo rmosolgo merged commit a539cd1 into master Feb 28, 2025
14 checks passed
@rmosolgo rmosolgo added this to the 2.4.11 milestone Feb 28, 2025
@rmosolgo rmosolgo deleted the fix-invalid-null-error-handling branch February 28, 2025 11:47
@rmosolgo
Copy link
Owner

Derp, sorry I overlooked #5256

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.

context.errors and InvalidNullError
3 participants