saleor: Move query-specific errors outside data in api response

What I’m trying to achieve

While making queries/mutations wrapper for API, I want a universal way of handling errors in the application when user input is wrong. Currently the only way to display validation response from backend, is to put it inside query and then when response is OK - look at keys in result and get errors as previously defined in query (nested inside). This will bypass the default error handling mechanism in GraphQL. This also means that by using the default Apollo configuration, it will not catch any errors and developer is forced to check the output data for errors key sitting inside.

Describe a proposed solution

Move all query/mutation specific errors to be returned in the response itself (adjacent to data). Errors should not be specified in the queries but instead be visible by default (when query fails). My proposed response scheme is following:

{
  data: {...},
  errors: { // errors key is only defined when there are errors present
    <mutationName>: Array // as previously done
  }
}

This also seems to be the general consensus of how these should be handled in GraphQL, as seen here: https://www.howtographql.com/graphql-python/6-error-handling/

If we were to go this direction, it’s crucial we still allow to query for errors using the “old” way, as this would be a breaking change for any front-end API response error handling. So it makes sense to support both for some time.

Useful links

https://blog.apollographql.com/full-stack-error-handling-with-graphql-apollo-5c12da407210 (example using Apollo-Server 2) https://docs.graphene-python.org/projects/django/en/latest/mutations/#form-validation

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 16 (14 by maintainers)

Most upvoted comments

I guess we could use the protocol-level error field through the extensions mechanism to do something like:

{
    "errors": [
        {
            "message": "Validation failed",
            "path": ["fooBarBaz"],
            "locations": [],
            "extensions": {
                "validation": {
                    "email": [
                        "INVALID"
                    ],
                    "firstName": [
                        "REQUIRED"
                    ]
                }
            }
        }
    ]
}

This would have the added benefit of the client being aware of the mutation failing.

patrys on Jul 1, 2019

As mentioned by @patrys, the shape of results.errors is something described by spec. It’s possible to extend those with additional information, and I know that Apollo server mentions this and even ships with few pre-made exceptions that cause additional data to appear on those - but trying to cram extra error details into result.errors results in increasing complexity on backend and frontend, and also cuts you off from some interesting features that apollo-client provides, like reverting optimistic update because mutation’s “failed” payload contained object without the changes - approach we are documenting in Ariadne’s “Error messaging” docshttps://ariadnegraphql.org/docs/error-messaging.

rafalp on Jul 1, 2019