GraphQL execution cancellation behavior changes between graphql-js v15 and v16

Direct answer

graphql-js v15 does not provide a built-in way to propagate an HTTP abort signal into the execution context. The reference execute function does not expose a standard abort signal, so cancellation is delegated to the transport layer. A server framework must map an HTTP client close event to a custom cancellation token or AbortController, expose it through contextValue, and require resolvers to check it cooperatively.

graphql-js v16 introduces an optional abortSignal on ExecutionArgs. This is the library's standardized cancellation signal, but it is advisory only: it does not forcibly stop a synchronous or non-cancellable resolver. Resolvers can inspect signal.aborted or forward the signal to cancellable APIs such as fetch or a database driver.

Confirmed facts versus likely behavior

Item	Status
GraphQL specification delegates cancellation to transport	Confirmed
Responses may contain both data and errors; partial data is valid	Confirmed
Non-nullable field failure nulls the nearest nullable ancestor	Confirmed
graphql-js v15 execute has no standard abortSignal	Confirmed for reference implementation
graphql-js v16 abortSignal availability across minor versions	Verify against installed package
HTTP close is automatically mapped to resolver cancellation	Not automatic; framework-dependent

Steps for this case

1. Confirm the installed version: npm ls graphql
2. If using v16, check the installed type definitions for ExecutionArgs.abortSignal before relying on it.
3. Wire your server framework's request-close event to an AbortController and pass its signal to execute.
4. In resolvers, check signal.aborted or pass the signal to async I/O; do not expect blocking synchronous work to stop.
5. On the client, treat any response with an errors array as partial. Inspect error.path against the requested selection set and avoid rendering data beneath nulled non-nullable ancestors.

Missing diagnostic detail

Which server framework and version are you using—for example Apollo Server, Express GraphQL, Mercurius, or another transport? The correct mapping of an HTTP abort to graphql-js execution depends on the framework, so this detail changes the implementation steps.

Assumptions and uncertainty

• Assumes the reference graphql-js execute function rather than a framework-specific wrapper with its own cancellation behavior.
• The exact abortSignal API shape and minor-version availability in v16 are not independently verified here; confirm against your installed package.
• Passing an AbortSignal signals intent only and cannot guarantee cancellation of blocking resolver work.

Practical version check: node -e "console.log(require('graphql/package.json').version)"