After parsing and validating an operation, a GraphQL server executes the requested selection set against the schema. Resolvers produce values for fields, and GraphQL recursively resolves nested selections.

A useful mental model is that GraphQL execution walks the requested response tree while resolving fields according to their types. The execution engine also tracks errors and associates them with the relevant response path.

GraphQL execution can resolve independent fields in ways that allow concurrency, depending on the execution engine and resolver behavior. This is useful when independent fields call different services.

Mutation root fields have special execution semantics because mutations are expected to execute their top-level fields serially. This allows clients to express ordered state-changing operations within one mutation operation.

Nullability is one of the most important concepts for understanding GraphQL errors. If a nullable field fails, GraphQL can return null for that field while preserving other successful data.

If a non-null field fails, GraphQL cannot legally return null for that field. The null value therefore propagates upward until it reaches a nullable parent or the root response.

This behavior means nullability is also an error-propagation design decision.

GraphQL can return both data and errors in the same response. This differs from APIs that treat every failure as an all-or-nothing HTTP response.

For example, a dashboard query may successfully return profile information and notifications while one downstream analytics field fails. If the schema allows that field to be nullable, the client can still render the rest of the dashboard.

GraphQL errors can include a path identifying where the failure occurred in the response tree. For a nested list, the path can identify both the field and the relevant list position.

This is valuable for debugging and client-side error handling because the client can determine which part of a large response failed instead of treating the entire operation as an opaque error.

Application errors should distinguish expected business failures from unexpected server failures.

Examples of expected failures include invalid input, insufficient permissions, unavailable resources, or business-rule violations. These can be represented using stable error codes and structured metadata.

Unexpected internal failures should be logged with diagnostic details while exposing a safe message to the client.

Directives can influence how a GraphQL operation is interpreted or how schema metadata is represented. Built-in directives such as @include and @skip allow clients to conditionally request fields.

Custom directives can also be used for schema metadata, authorization patterns, caching hints, validation, or tooling. However, directives should not become a substitute for clear application architecture.

A GraphQL operation moves through several stages before the final response is produced.

Test your understanding of GraphQL null propagation.