Q3 of 20 · GraphQL
What is partial success in GraphQL, and why does it matter for testing?
GraphQLMidgraphqlerror-handlingedge-casesapi
Short answer
Short answer: A single response can contain both `data` (fields that resolved) and `errors` (fields that failed) at the same time. Tests that assume the two are mutually exclusive will silently pass half-failed responses.
Detail
Because a GraphQL query can request many fields, each backed by its own resolver, some fields can succeed while others fail. The response then carries both data (with the successful fields, and null for the failed ones) and errors (describing the failures).
{
"data": { "user": { "name": "Alice", "paymentMethod": null } },
"errors": [
{ "message": "Forbidden", "path": ["user", "paymentMethod"], "extensions": { "code": "FORBIDDEN" } }
]
}
Testing implications:
- Don't write
if (errors) fail()orif (data) pass()as exclusive branches — check both. - A field returning
nullis not automatically a bug; cross-reference theerrorsarray'spathto see whether that null is an expected error or genuine data. - Partial success is the mechanism behind subtle authz leaks and resolver failures that a naive "did I get data back?" check will miss.
// WHAT INTERVIEWERS LOOK FOR
Awareness that data and errors coexist, and that the path field ties an error to the field that produced the null.
// COMMON PITFALL
Treating any non-null data as success — a response with data AND errors is half-broken and needs both inspected.
// Related questions