I just ran into an issue while using Apollo Client with Hasura. Since Hasura always returns a 400 status code when there's an error in the query, Apollo Client will always treat that error as a networkError and not pull the graphql errors out of the response.
Apollo client expects a query with non-fatal errors (it seems like that means if there's a query with optional fields that fail) to return as a 200 with the errors property instead of the data property.
Can the status codes be changed in Hasura to have full compatibility with Apollo Client?
The GraphQL spec doesn't say anything about the transport layer and the HTTP best practices section on graphql.org doesn't talk about status codes. I think the only sane option left is to check what the most popular graphql clients expect and decide based on that? @coco98 @shahidhk
Related: https://github.com/hasura/graphql-engine/issues/1019
Makes debugging Apollo requests hard :(
Isn't Apollo one of the most popular clients? 10k Github stars, 526,150 weekly npm downloads.
Since graphql spec supports errors in body response, i think treating it as error or not is client's responsibility, not server's responsibility.
Only network error (like being offline) is the only type of error to me.
The new /v1/graphql will have this behaviour. Will be part of the next release.
I have the same issue when trying to use tornado.httpclient. It just tells me there's an error but doesn't say what it is.
Body seems fine- doing same request through postman works. Seems like a permission issue but I have no clue which permissions I might be lacking.
EDIT:
Using v1 instead of v1alpha1 fixed my problem - I got a response sayin that something should be an object instead of a string - I was passing a stringified Json (with json.dumps) instead of just passing a dictionary.
The error still doesn't say which property should be an object, because it looked like below:
b'{"errors":[{"extensions":{"path":"$","code":"parse-failed"},"message":"When parsing the constructor GQLReq of type Hasura.GraphQL.Transport.HTTP.Protocol.GQLReq expected Object but got String."}]}'
Most helpful comment
The new
/v1/graphqlwill have this behaviour. Will be part of the next release.