Apollo-link: ErrorLink: unable to get graphQLErrors

[gpoitch]

I'm using the ErrorLink code from the documentation: https://www.apollographql.com/docs/link/links/error.html#Usage

My server for example returns a 400 status and the following payload if the query contains an invalid field:

{"errors":[{"message":"Cannot query field \"bogus\" on type \"Article\".","locations":[{"line":4,"column":5}],"code":"bad-request","statusCode":400}]}

In this case, the next hook of the link's observable is never called thus result.errors never gets a chance to be parsed and I can only get a network error back instead of result.errors as graphQLErrors

[ghost]

I too have been experiencing the same issue. I'm successfully composing a number of links but never get the graphQLErrors object returned.

Do you call your mutations directly from the client object? Or compose them in a graphql container of some description?

[gpoitch]

I call mutations in a container generally, but do both ways. I can reproduce this however with just a simple query and purposely inserting an unknown field.

Even constructing a custom Link instead of using ErrorLink, I can never parse the errors because the observable's next hook isn't called with the data.

[ghost]

I managed to resolve this but it was unrelated to apollo-link and your issue unfortunately.

My graphql server was returning the error object with a key of 'error'. When this was changed to 'errors' it returned the object as expected.

[gpoitch]

This appears to be happening because http-link exits early if the response.status >= 300
https://github.com/apollographql/apollo-link/blob/0fd802709f452eb11eb3a52ae2fb49667d073cc2/packages/apollo-link-http/src/httpLink.ts#L21-L24

Not sure if that is bug with http-link, or my backend should be returning 200 even with errors.

[evans]

@gpoitch I think this comes down to how we define a NetworkError vs GraphQLError. A NetworkError is defined by anything with a status that is >= 300, while a GraphQLError is an error returned in the errors field of a 200 level response.

Your use case is interesting in that you return a GraphQL result on a network error. I do agree that the http link should return the response if it parses despite the network status code, so that links up the chain can react to a NetworkError that returns a valid GraphQL result, which could contain errors or data.

Looks like that would involve adding the result object to the error (here)[https://github.com/apollographql/apollo-link/blob/0fd802709f452eb11eb3a52ae2fb49667d073cc2/packages/apollo-link-http/src/httpLink.ts#L20-L24]. Does that make sense for what you would be trying to do?

CC @peggyrayzis @jbaxleyiii

[gpoitch]

@evans yes if I could at least get access to the response from the HttpLink I'd be happy with that and can do my own error parsing. Thanks for responding!

[TomPridham]

Does it specify somewhere that all graphql queries should return 200s? It feels kind of wrong to have the backend return a 200 when the query/mutation failed. Also, is this change documented anywhere? All of our error handling broke when we upgraded from 1.x and it would be nice to have something in the docs that mentions this.

[evans]

@gpoitch Take a look at #244 and let me know if I missed something/feel free to add your own changes

@TomPridham The specification does not mention anything about what the server should do with respect to HTTP status codes. I agree it would be wrong for 200's to be returned on all errors. At some point I think there should be a distinction between network errors(ie authentication) and GraphQL errors(ie improper arguments). #244 tries to make that separation clear and allow for GraphQL results to be returned on Network Errors. Apologies for the lack of documentation. We removed Apollo Fetch(used to handle the error behavior) from the interior of the HTTP link, so #244 should add the missing information. Please comment if it doesn't!

[gpoitch]

@evans looks great! Will comment on the PR

[pleunv]

I'm also having a use case where a > 300 status code still returns a (partially) valid response, i.e. if a user does not have sufficient privileges to perform one of the operations the response will be a 403 - Forbidden, but the other operations might still succeed and the GraphQLError for the failed operation will also be passed in the result. Currently I cannot access this, and it's not clear to me if #244 changes anything to this behavior?

edit: After re-reading the proposed change, more specifically this:

Since many server implementations can return a valid GraphQL result on a server network error, the thrown Error object contains the parsed server result.

...I'm assuming it will? If so, great! 😄

[jbaxleyiii]

This should be fixed thanks to @evans work on #244! I'm working to release it asap!