Absinthe: Improve format of errors response

[hisapy]

As mentioned in the Slack channel, I'd like to improve the error messages format so they can be easier to handle in the frontend.

Currently, the errors look like the following:

{
  "errors": [
    {
      "message": "Argument \"input\" has invalid value $input.\nIn field \"turno\": Expected type \"String!\", found null.\nIn field \"secretaria\": Expected type \"String!\", found null.\nIn field \"acreedorId\": Expected type \"ID!\", found null.","locations":[]
    }
  ]
}

The above is an example of an input object used in a mutation. As you can see, there is only one message key and all the errors are in the same string. What I suggest, if possible, and of course, if it makes sense, is to parse the errors, so they can be returned with the following format

{
  "errors": {
    "input": {
      "message": "Argument $input has invalid value", 
      "fields": {
        "turno": ["Expected String!, found null"], 
        "acreedorId": ["Expected type ID! found null"]
       }
      }
    }
}

Then it would be easy to get the errors of a given field. What do you guys think?

[benwilson512]

Hey @hisapy. As a general rule we've simply followed the wording used by the reference implementation graphql-js. If that's changed then we should change as well, but I do want to maintain parity with the wording it uses.

Validation errors like this are generally aimed at GraphQL developers. A user of the front end shouldn't be able to send an invalid GraphQL doc, so there generally shouldn't be a need for the front end to display validation errors to an end user.

[bruce]

Another view: I think parity with the message is a good idea (we need to verify that parity is up-to-date, too), but having something in addition (at least as an option), similar to how path made things easier, is an interesting thing to investigate. For instance, some type of pattern for validation phase configuration that allows extensibility of error-adding.

[hisapy]

Hi @benwilson512 and @bruce , thanks for the quick response.

Validation errors like this are generally aimed at GraphQL developers. A user of the front end shouldn't be able to send an invalid GraphQL doc, so there generally shouldn't be a need for the front end to display validation errors to an end user.

Yeah, I forgot about this when writing this issue.

The _problem_ is that I'm using Relay Modern, and it lets you commit a mutation with an invalid document. Moreover, I'm using the single input object approach and when the input is missing, you just get a warning, however, when the input is present but there are invalid fields in it, Relay does nothing to prevent the mutation going to the server. In other words, the input object fields are not _validated_ by Relay. So, with this in mind, and the assumption that this client validation can be skipped if someone _modifies_ the Javascript in the page, I was thinking on relying on server errors not to render them directly to the user, but instead parse them so they become nice and user readable.

I was also thinking that if I completely remove the field validations in the GraphQL (Absinthe) layer, I could still rely on my backend (Ecto) errors, but in that case my schema will loose the ability to render errors in programs like GraphiQL.

Anyways, I'm not familiar with the reference implementation, but from the October 2016 GraphQL specification,

GraphQL servers may provide additional entries to error as they choose to produce more helpful or machine‐readable errors, however future versions of the spec may describe additional entries to errors.

I think we have a window to _improve_ the error response, perhaps implementing @bruce's idea. In this sense, I think machine-readable errors could be just a mean to communicate with end users through developers. As a developer, I'd like these errors to be easier to parse so I can inform the end user that some fields are invalid.

I know this is not something critical and is subject to become something opinionated so I guess either choice you make as maintainers of this awesome lib is going to be the right choice. In the meantime, I'll see what I can do either in Javascript or perhaps a middleware to add an special error field just for my use case.

[bruce]

I think we have a window to improve the error response, perhaps implementing @bruce's idea.

Yeah, I think the "line in the sand" for us is probably anything that forces error objects on Absinthe users that go beyond the standard—we don't want our error objects to be seen as "Absinthe-flavored."

If, instead, we support a way to easily hook into the error struct generation to customize how they're built, we get the best of both worlds.

[hisapy]

The best of both worlds sounds nice
:)

[hisapy]

Hey guys, I just found that GraphQL specification for errors changed from the last time I checked it. Now it talks about path and extensions keys.

See http://facebook.github.io/graphql/draft/#sec-Errors

[binaryseed]

Closing this since it's covered by extensions...