GraphQL New Added 17 October 2026

GraphQL: Unknown argument "first" on field "Query.users"

Validation rejected the query before any resolver ran because the schema has no argument with that name on that field. It is often a client written against a different schema version, a Relay-style first/after query sent to a server that paginates with limit/offset, or a field that takes its options inside an input object rather than as loose arguments.

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

# Ask the server which arguments the field really takes
curl -s -H 'Content-Type: application/json' https://api.example.com/graphql \
  -d '{"query":"{ __type(name: \"Query\") { fields { name args { name type { name kind } } } } }"}' \
  | jq '.data.__type.fields[] | select(.name=="users")'

# Regenerate client types from the live schema so the mismatch is caught at build time
npx graphql-codegen --config codegen.ts

# Then use the name the schema exposes, for example
# query { users(limit: 10, offset: 0) { id } }
# or, if it takes an input object
# query { users(page: { first: 10 }) { id } }

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.

spec.graphql.org graphql.org

Related GraphQL errors

See all 19 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.