GraphQL always returns HTTP 200 for a successful transport; problems are reported in the response body, not the status code. A response has two top-level keys: data and errors, and both can be present at once — that is partial data.
If one field's resolver throws, that field becomes , an entry is added to , but every other field still resolves. The client gets what succeeded plus a description of what failed.
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // exactly which field failed
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
The extensions.code field carries a machine-readable error code so clients can branch on it. Whether a thrown field nulls only itself or bubbles up depends on nullability: a non-null field (posts: [Post!]!) that errors nulls its nearest nullable parent instead.
import { GraphQLError } from "graphql";
const resolvers = {
Mutation: {
transfer: (_p, args, ctx) => {
if (!ctx.user) {
// attach a stable code clients can switch on; hide internal details
throw new GraphQLError("Not authenticated", {
extensions: { code: "UNAUTHENTICATED" },
});
}
// ...
},
},
};
Many teams also model expected errors (validation, "email taken") as part of the schema via union/result types, reserving the errors array for unexpected failures — keeping happy-path typing clean.
Interviewers probe whether you know errors live in the body with partial data, that codes belong in extensions, and that nullability controls how far an error bubbles. Confusing GraphQL errors with HTTP status codes is a classic tell that someone has only used REST.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate