graphQLErrors property passed to onError is sometimes an empty string

[6XGate]

Issue Description

The type definitions for the onError link shows that graphQLErrors should always be an array of errors. Unfortunately when some servers return a 500 error, it will be an empty string.

Link to Reproduction

See repro steps

Currently I have to use the following code to prevent this from happening

onError(({ networkError }) => {
  if (networkError != null && 'result' in networkError && typeof networkError.result !== 'object') {
    networkError.result = { }
  }
})

Reproduction Steps

It is difficult to create a reproduction case with the given templates. Though I can if needed. But, the offending code is in at /src/link/error/index.ts:63 and may be a lack response parsing sanity checking or sanitation earlier on. It may also be that using a chaining of && should be replaced with something that ensures the networkError result is an object and not something else.

[hichemBAALI]

Any update here. I am still having the graphQLErrors: undefined when authLink fails (token expires). Please let me know if anyone faced the same issue

[6XGate]

Any update here. I am still having the graphQLErrors: undefined when authLink fails (token expires). Please let me know if anyone faced the same issue

That would likely come in as networkError if the error is indicate via an HTTP status code like 401 or 403. AFAIK, getting those will results in an undefined graphQLErrors value. But, I filled this issue due to sometimes getting an empty string in those cases rather than undefined.

[jerelmiller]

@6XGate this definitely seems like a bug, good catch! We should absolutely make sure that graphqlErrors never get set as an empty string in the event the server response is empty.

Would you be open to submitting a PR to get this fixed? I'd be more than happy to review it.

[6XGate]

Can if I get a chance.

[euc-callum]

We're also seeing this for 502 errors 👍

[fe-jcorreia]

This issue was fixed for new versions?

[jerelmiller]

@fe-jcorreia nope this is still an issue. I'm just realizing though that we have #11329 open to address this. We'll see if we can get a review on that one soon. Thanks for the nudge.

[Tadimsky]

I just ran into this issue for our product, causing us to not handle the errors properly and silently fail.
It was for a 405 error response from our reverse proxy, we had just an empty string:

Is there a chance we can get this PR merged at some point? @jerelmiller

[jerelmiller]

@Tadimsky gah thanks for the reminder. I've had a tab open to review it for a while and it kept slipping my mind. Just reviewed the PR that fixes this and will get it in the next patch release which should go out later this afternoon.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
For general questions, we recommend using StackOverflow or our discord server.