[graphql-client] Improves error handling for missing Response.body in multipart requests

[ecbrodie]

WHY are these changes introduced?

This fix was motived by development of an internal library that serves as a consumer of the graphql-client package.

We detected instances of errors in multipart GraphQL requests where, for some reason, Response.body was undefined despite a 200 OK response. This seems to occur mostly (if not always) on frontends that use a custom window.fetch implementation.

The symptom of this error would be the following message: Cannot read properties of undefined (reading 'Symbol(Symbol.asyncIterator)').

I deduced this error to be caused by a check in createMultipartResponseAsyncInterator() where there is an assumption, via response.body![Symbol.asyncIterator], that response.body is always defined, especially for responses with a truthy response.ok value. Clearly this is not a safe assumption to make, especially in web environments where the fetch implementation acts in unexpected ways.

WHAT is this pull request doing?

By using optional chaining instead of the non-null assertion operator, we avoid an unexpected behaviour from attempting to read a property from an undefined response.body and instead fall back to throwing the existing error message, which I believe is indeed the more expected result of this situation: API multipart response did not return an iterable body.

Type of change

• Patch: Bug (non-breaking change which fixes an issue)
• Minor: New feature (non-breaking change which adds functionality)
• Major: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• I have used pnpm changeset to create a draft changelog entry (do NOT update the CHANGELOG.md files manually)
• I have added/updated tests for this change
• I have documented new APIs/updated the documentation for modified APIs (for public APIs)

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

[lizkenyon]

Thank you! ⭐

[lizkenyon]

Let's explicitly say that now API multipart response did not return an iterable body is thrown in this case.

[ecbrodie]

@lizkenyon are you able to also confirm here that the failing Changelog Check does not impact this PR's ability to merge?

After I apply your review suggestion, would you like me to trigger the merge or is that more for you to do?