rmosolgo / rmosolgo/graphql-ruby

GraphQL error code pattern

Open
#5,221 1 comment 0 reactions 0 assignees View on GitHub

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

https://github.com/rmosolgo/graphql-ruby/blob/5ec4b1ba7857a536aafe61c2f726ee599a18febb/lib/graphql/static_validation/rules/argument_literals_are_compatible_error.rb#L43-L45

https://github.com/rmosolgo/graphql-ruby/blob/5ec4b1ba7857a536aafe61c2f726ee599a18febb/spec/graphql/schema/scalar_spec.rb#L133-L145

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.