Fix type signature of ServerError

[dleavitt]

ServerError#result will be a string when the response has a >= 300 status code and isn't json.

It looks like maybe there was a breaking change in parseAndCheckHttpResponse.ts when adding defer support in 3.7.

• Previously, a non-json response would always result in a ServerParseError. So ServerError's result would always be JSON.
• Now, the status code check happens first so you get a ServerError (with a string result) instead.

Maybe this is a bug? The old behavior seems better.

Checklist:

• If this PR contains changes to the library itself (not necessary for e.g. docs updates), please include a changeset (see CONTRIBUTING.md)

[netlify]

‼️ Deploy request for apollo-client-docs rejected.

Name	Link
🔨 Latest commit	bd1e0fd

[apollo-cla]

@dleavitt: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/

[changeset-bot]

🦋 Changeset detected

Latest commit: f17b34b

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@apollo/client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[alessbell]

Hi @dleavitt 👋 Thanks for opening this PR!

You're correct that the behavior slightly changed here in 3.7: previously, if a request returned a response with >= 300 status code and string body, ServerError.message would have been a JSON parse error, e.g. "Unexpected token 'E', \"Error! Foo bar\" is not valid JSON" and ServerError.result was undefined. In 3.7 and later, ServerError.message is Response not successful: Received status code 302 and ServerError.result is the string from the response.

I've added a test case and small related TS fix: expanding ServerError.result to include string caused TS errors in the persisted query link where network errors are being cast to GraphQLErrors for a very specific reason (see: #9410); reworking the way that type is narrowed allows us to accurately reflect reality in the ServerError type.

[jerelmiller]

This looks great to me! Thanks for getting this fixed! 🎉

[dleavitt]

@alessbell good catch, thanks so much!