If an exception occurs during a GraphQL request, the response is HTTP 400 with content similar to this:
HTTP 400
{
"errors":[
{
"debugMessage":"wtf",
"message":"Internal server error",
"category":"internal",
"locations":[
{
"line":2,
"column":3
}
],
"path":[
"updateUser"
]
}
],
"data":{
"updateUser":null
}
}
This is quite confusing as general the UI would like to catch these types of errors and display some sort of global notification. Validation errors also produce a similar HTTP 400, so the only way to tell that the response is an issue with the server is to go looking at the content.
By contrast, the REST API returns an HTTP 500 for exceptions so it is easy to distinguish by the client.
It looks intended to me. Unlike REST, several GraphQL queries can be embedded in the same HTTP request. The first query can return an error, and the one be successful.
It is intended: https://github.com/api-platform/core/blob/master/src/GraphQl/Action/EntrypointAction.php#L70
I think we should even set a 200 instead of a 400. GraphQL is not related to HTTP like REST.
Thanks for showing me again why GraphQL is evil. :laughing:
@alanpoulain I would expect a 200 response if this is how errors are being handled.
I guess I will need to rethink my error handling strategy for graphql calls. Thanks everyone for the input.
@bwegrzyn I've done a PR to avoid confusion for developers by always sending a 200, even when there are errors.
Most helpful comment
Thanks for showing me again why GraphQL is evil. :laughing: