SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
GraphQL New Added 28 August 2026

GraphQL: PersistedQueryNotFound

With automatic persisted queries the client first sends only a hash. If the server has not seen that query before (a cold cache, a new deploy, or a multi-instance server without a shared cache) it responds with PersistedQueryNotFound and the client must resend the full query.

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
# This is expected once per query; the client should retry with the full text.
# Apollo Client does this automatically with createPersistedQueryLink.

# If it happens on every request:
# 1. The server's APQ cache is not shared across instances. Use Redis
# 2. The hash algorithm differs (must be sha256 of the exact query string)
# 3. A CDN is caching the GET but not the POST fallback

# Consider build-time persisted queries instead, which remove the
# round trip and let you reject unregistered operations.

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.

  1. Always inspect the errors array, not just the HTTP status. Each entry carries a path that points at the exact field that failed.
  2. Validate the query against the schema locally before sending it. GraphQL IDEs and graphql-codegen catch every validation error at build time.
  3. 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.
  4. 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.
  5. 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.