Spring GraphQL errors: distinguish validation, resolver failure and nullable data

Inspect both result channels

A document omitting the required limit argument fails schema validation before the list fetcher executes. A list request with limit 47 reaches the fetcher, which rejects it. Both return errors, but they are different failure stages. The checked schema marks receipts non-null, so the rejected fetcher clears root data. A cross-tenant nullable receipt lookup returns receipt: null without an error. Clients must not assume every null means the same thing.

The fixture uses GraphQL Java's default exception handling and does not define a public error code or sanitization policy. A production GraphQL service should map known domain failures into stable public extensions and keep stack traces and internal values out of the response. REST ProblemDetail is a different transport shape; reuse domain categories, not the HTTP envelope.

Measure what the response hides

A successful HTTP status can still carry GraphQL errors. Transport tests should assert the JSON errors and data tree, and monitoring should count application failures separately from HTTP status. The source kit executes the schema directly, so it cannot establish deployed status codes, authentication errors, CORS or request-size controls.

Checked excerpt

ExecutionResult rejected = source.graphQl().execute(
    ExecutionInput.newExecutionInput()
        .query("{ receipts(limit: 47) { id } }")
        .graphQLContext(Map.of("tenant", "north"))
        .build());
assertFalse(rejected.getErrors().isEmpty());
assertNull(rejected.getData());

Verification boundary

The Java 21 / Spring Boot 4 source kit checks missingRequiredArgumentIsRejectedBeforeFetcher, oversizedListRequestReturnsGraphQlError and tenantCannotReadAnotherTenantsReceipt.

Cost and limits

Validation and execution both consume CPU; errors in non-null branches can discard otherwise useful selected data. The local test checks result structure, not network serialization, exception redaction or monitoring cardinality.

Common Mistakes

• Do not inspect only the HTTP status when handling GraphQL failures.
• Do not assume a null field always indicates a resolver exception.
• Do not forward raw internal exception text as a public error policy.

Read next

Spring GraphQL schema nullability: trace one field failure through the response, Spring GraphQL list bounds: reject large arguments before reading rows, Spring MVC ProblemDetail: stable errors without leaking internals, Spring GraphQL service tests: stop short of claiming an HTTP endpoint, Spring MVC validation errors: one public ProblemDetail for two failure paths.