GraphQL error code pattern

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.

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.