[clement911]

Alternative to #15, with a design based on the existing GraphQL types and the GraphQL over HTTP spec.

What

When a request fails with a non-success HTTP status, GraphQLHttpException now exposes:

• ResponseBody (string): the raw response body, or null if it was empty or could not be read.
• Response (GraphQLResponse): set when the body is a GraphQL response, otherwise null. It is parsed only when the content type is application/json or application/graphql-response+json and the body has errors or data. It reuses the existing GraphQLError model, so extensions (e.g. code), path and locations are kept.

The exception message adds the GraphQL errors when they were parsed. Otherwise it adds the raw body, truncated to 1000 characters.

Design notes

• The HTTP error is always preserved. Reading and parsing the body is best effort. Any failure, including I/O errors, cancellation and invalid JSON, is swallowed, so the client still throws GraphQLHttpException and RetryInterceptor behaves as before.
• Follows the GraphQL over HTTP spec. A non-2xx body may come from an intermediary such as a proxy or gateway, so non-JSON bodies are never parsed. JSON that doesn't look like a GraphQL response stays only in ResponseBody.
• Only spec-compliant error responses are parsed. errors must be an array of error objects. Any other shape, such as a string errors, leaves Response null and is only available through ResponseBody and the message.
• No breaking change. The existing constructor stays, and a new overload takes the body and the parsed response.

Tests

GraphQLHttpExceptionTests covers:

• a spec-compliant 400 response with extensions
• a non-array errors
• non-GraphQL JSON
• an HTML 502 with truncation in the message
• an empty body
• retries still happening when the error body is a GraphQL error

🤖 Generated with Claude Code