graphql-client icon indicating copy to clipboard operation
graphql-client copied to clipboard

Deserialize non-specified entries in GraphQLError

Open ilia-cy opened this issue 3 years ago • 3 comments
trafficstars

We recently upgraded the client from version 1.0.3 to 4.0.2 (quite an upgrade, I know). One of the changes that we noticed is a change to the GraphQLError class. In version 1.0.3, each GraphQLError held an AdditonalEntries dictionary which held raw fields on the response error.

In version 4.0.2, the GraphQLError class was changed. Fields such as path and extensions were added to it and the AdditionalEntries was removed.

For example, here is an error received from Github:

{
	"errors": [
		{
			"type": "INSUFFICIENT_SCOPES",
			"locations": [
				{
					"line": 4,
					"column": 28
				}
			],
			"message": "<some_message>"
		}
	]
}

In 1.0.3, the type field was part of the AdditonalEntries dictionary. When running the same query in 4.0.2 and receiving the same error, it seems that the type field is nowhere to be found.

We had logic based on the value of that field. For example, Github returns specific error types for different errors (INSUFFICIENT_SCOPES, PLAN_NOT_SUPPORTED, RATE_LIMITED, FORBIDDEN, and more).

So my questions are:

  1. Did I miss a way of retrieving the type error field?
  2. If not, any suggestion on how to handle the errors properly without that field?

Since GraphQL always returns a 200 OK and we need to detect errors based on the response, how do you suggest we map the specific errors now that this field is gone? A possible solution is parsing the message field and running regular expressions on them, but that is really awkward and something I wish to avoid.

Thanks

ilia-cy avatar Mar 22 '22 09:03 ilia-cy

Hi ,

I'm sorry for your inconvenience. If you go by the section on errors in the GraphQL Spec, additional error fields in the GraphQL response should be put into the extensions map (which is supported by this client), which GitHub is unfortunatelly not doing in their API. That type field falls under the red boxed example (not forbidden, but discouraged).

If I remember correctly this functionality "broke" when we eliminated the use of dynamic, because some runtimes/platforms don't support that.

I think it this could be reimplemented by creating specialized converters for a GraphQLError, the existing MapConverters seem like a good starting point.

I'll happily accept a PR 😉 which supports this with both derializers, since this is indeed covered by the spec (albeit discouraged)!

rose-a avatar Mar 24 '22 21:03 rose-a

Is this issue still pending? I hit the same problem with the Github GraphQL API, getting information on a repository but if it's deleted it returns type: "NOT_FOUND" in the error, but there doesn't seem to be a way to get this type with this library?

Haven't dug much into the code but will have a look next weekend if nobody else is working on it

zakeryooo avatar Feb 05 '23 23:02 zakeryooo

Yep, still pending

rose-a avatar Feb 06 '23 10:02 rose-a