`SHOULD not contain the data entry on JSON parsing failure when accepting application/graphql-response+json` also fails on non-JSON responses

[David Glasser]

The audit SHOULD not contain the data entry on JSON parsing failure when accepting application/graphql-response+json does this:

        assert(
          'Data entry',
          (await assertBodyAsExecutionResult(res)).data,
        ).toBe(undefined);

This will throw if the body is not actually JSON, with the misleading error about "SHOULD not contain the data entry".

First, I'm not actually sure if the spec actually has a SHOULD that JSON parse errors should be returned as JSON at all (as opposed to having opinions about its structure if it is JSON). Apollo Server now expects you to use your web framework's JSON parsing capabilities (eg, body-parser with Express) rather than handling it "in-house" and it is primarily structured as a non-error-handling middleware, so it's challenging for us to respond to invalid JSON with any particular error format. Maybe that's a self-imposed limitation but we're probably not going to change it. But I don't really see anything that says you SHOULD have a JSON response here. There's

When a server receives a well-formed GraphQL-over-HTTP request, it must return a well‐formed GraphQL response.

but in this case there is no well-formed request, so that doesn't apply.

Second, even if this is a legitimate thing to (optionally) test for, I think it should probably be explicitly tested for separately from this test case, and this particular test shouldn't fail claiming there's a data entry where there really isn't one. ie if the response is not JSON at all then I think this test should pass?

[Denis Badurina]

This is a great argument, we should not audit the errors format during content parsing issues. Will be fixed with #47.

However, I'd say we keep the other tests that expect JSON formatted results failing on parsing issues. We are actually testing a server that's expected to serve GraphQL.

Will leave this one and these ones though, the client does expect this behaviour.

[Denis Badurina]

🎉 This issue has been resolved in version 1.13.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀