GraphQL New Added 9 September 2026

Apollo Client: Missing field 'x' while writing result to the cache

The normalised cache stores objects by id and typename, and the response left out a field the cache needed, usually because one query selects a subset that a fragment elsewhere expects. It is only a warning, but the later read returns incomplete data and refetches, which looks like a caching bug rather than a query one.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix

// Every query on a normalised type has to select its id
query { orders { id status customer { id name } } }

// Types keyed on something other than id need a policy
new InMemoryCache({
  typePolicies: { Order: { keyFields: ["reference"] } }
})

// Fields computed per query should not be normalised at all
typePolicies: { Order: { fields: { totalWithTax: { merge: false } } } }

// Inspect what actually went into the cache
console.log(JSON.stringify(client.cache.extract(), null, 2))

// Writing by hand: the data must match the query's selection exactly
cache.writeQuery({ query: ORDERS, data })

How to diagnose GraphQL errors

GraphQL returns HTTP 200 with an errors array far more often than it returns a non-2xx status, so clients that only check the status code silently ignore failures. Errors split into validation (the query does not match the schema, always fixable from the schema), authorisation (per-field resolvers rejecting), and performance guards (depth and complexity limits) which exist to protect the server from expensive queries.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

Always inspect the errors array, not just the HTTP status. Each entry carries a path that points at the exact field that failed.
Validate the query against the schema locally before sending it. GraphQL IDEs and graphql-codegen catch every validation error at build time.
For N+1 problems, enable resolver tracing or SQL logging and count queries per request. A DataLoader that batches by key is the standard fix.
When you hit a depth or complexity limit, restructure the query rather than raising the limit. The limit is usually protecting the database from an unbounded traversal.
Check whether the error is from the gateway or the subgraph in a federated setup; the two have separate schemas and separate authorisation.

Tools worth reaching for

GraphiQL / Apollo Sandbox
graphql-codegen
Apollo tracing
DataLoader

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

apollographql.com

Related GraphQL errors

See all 13 GraphQL errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.