Question about the gem's use of errors.extensions

[odinhb]

I recently implemented my own extensions to some graphql errors and based some frontend error handling on it. Looking at https://spec.graphql.org/June2018/#sec-Errors I implemented my own things under the extensions key. It looks something like this:

{
  "data": null,
  "errors": [{
    "message": "my message",
    ...
    "extensions": {
      "code": "COOL_CODE",
      "other_thing": "...",
    }
  }]
}

However I discovered that this gem collides with my extensions. The server returned this error when I violated my schema:

{
  "errors": [{
    "message": "InputObject 'SomeObject' doesn't accept argument 'someArgument'",
    "locations": [{
      "line": 2,
      "column": 43
    }],
    "path": ["mutation myMutation", "mutationName", "input", "someArgument"],
    "extensions": {
      "code": "argumentNotAccepted",
      "name": "SomeObject",
      "typeName": "InputObject",
      "argumentName": "someArgument"
    }
  }]
}

My concern with this error is that I implemented my own behaviour tied to extensions.code. In other words, your error extensions are colliding with mine.

What I'm wondering is where are these errors documented? Is this the only one? As I implemented behaviour dependent on this json I'd like an overview of what keys are used by the gem already.

I also suggest namespacing the gem's errors like this:

{
  "errors": [{
    "extensions": {
      "gql-ruby": {
        ... this doesn't affect me unless I want it to
      }
    }
  }]
}

Versions

graphql version: 1.10.9 rails: 5.2.2

[rmosolgo]

Hi, thanks for the writeup here. That's a good point about conflicts -- I think we upstreamed this from our implementation at GitHub, but I didn't think about the downside.

What I'm wondering is where are these errors documented? Is this the only one?

They aren't :S . I think all the static validation errors have extensions like that, though.

Instead of namespacing, would it suit you if the gem stopped emitting these extensions altogether? I think we could add a setting to opt out.

[odinhb]

Instead of namespacing, would it suit you if the gem stopped emitting these extensions altogether? I think we could add a setting to opt out.

That would also be fine for me at the moment. I still like my original suggestion better, though. It would let me opt-in rather than opt-out.

[rmosolgo]

I do like the idea of tempering this gem's use of extensions, but since nobody else has commented in a long time and I don't have plans to work on this, I'm going to close the issue.