rmosolgo / rmosolgo/graphql-ruby
GraphQL error code pattern
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 5.4k
- Forks
- 1.4k
- Avg merge
- 23h 19m
- Merged PRs (30d)
- 28
Description
Is your feature request related to a problem? Please describe.
Request for guidance around GraphQL error's extensions.code (spec example). For static validation, the different errors have a camelCase value. Other errors like ParseError and more broadly ExecutionError usages don't make any attempt to provide a code.
We're looking to expand usage of the concept of an error code more broadly to have a more reliable way to group errors together, and was wondering about how this gem was thinking about classifying different types of errors.
Example
Describe the solution you'd like
Discuss the notion of an error code for gem related functionality and its format.
Easier to reliably have content added to extensions.
Contextual
There are some cases like raise GraphQL::CoercionError where having additional runtime information would help. This error can be raised by user input (client) and persisted data (server). Having an awareness of which scenario is resulting in this exception would help attribute who is responsible for fixing this invalid state. Essentially allowing us to distinguish between HTTP 400 bad input and 500 bad response.
Describe alternatives you've considered
I acknowledge ExecutionError accepts extensions, where code can be provided. But for cases where gem code raises such an exception (e.g. CoercionError), it is annoying to patch / inject a code later on via custom processing.
Additional context
We (Shopify) already have custom codes that predate the static validation ones in CONSTANT_CASE (e.g. TIMEOUT, THROTTLED, INTERNAL_SERVER_ERROR), but we can deal with different formats if need be.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with lib/graphql/static_validation/rules/argument_literals_are_compatible_error.rb and spec/graphql/schema/scalar_spec.rb, then review the issue's references to ExecutionError and CoercionError. Compare existing camelCase and CONSTANT_CASE codes, including how extensions are populated. Done would require an agreed convention for classifying gem-raised errors and their contextual information.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100