apollo-link
apollo-link copied to clipboard
apollographql
HTTP link is masking underlying errors.
createHttpLink would mask a graphQL error with an error code 400, if one of multiple simultaneous request fail. On the other hand BatchHttpLink, would show the proper error msg.
In my case the error msg which was "masked" by createHttpLink and revealed by BatchHttpLink was message: "Fragment "ProfileFields" is never used."
I just came here to write a similar thing about the HTTP link masking errors, I don't know if I should raise a separate issue.
In my instance, the HTTP link will mask an underlying network error; ie, the GraphQL endpoint being queried returns a HTTP 504 Gateway Timeout with a HTML page describing the error. But the actual error thrown by the HTTP link is a "ServerParseError" (Unexpected token < in JSON at position 0) because the HTTP link has attempted JSON.parse() on the HTML.
In my tests it's actually impossible to capture this type of error because the stack traces are disconnected, ie the application sees the thrown ServerParseError, but only Apollo's error-link sees the actual operation and the root cause being a HTTP Gateway Timeout.
The result is the error logs fill with "Unexpected token < in JSON at position 0" rather than the root cause, the API is timing out.
Perhaps rename the ticket to simply HTTP link is masking underlying errors.
This PR can solve the issue @samkelleher is facing: https://github.com/apollographql/apollo-link/pull/1028 For the one @Jaikant is facing it's quite hard to know what's the issue but I'll try to look into it asap.
It looks like the networkError's response body can still be accessed at error.result (for ServerErrors) or error.bodyText (for ServerParseErrors)
~~Accessing the response body is a good workaround, still it would be nice if apollo-link-http-common didn't try to parse every response as JSON, only those that have the application/json content type.~~ Sorry, missed the discussion over on #1028
Someone mentioned in this or #1028 that this is caused by the downstream server returning HTML for a > 3xx error which is a "misconfiguration"
On AWS, all application load balancers return HTML with e.g. a 504 timeout and this is not configurable.
