A GraphQL field declares arguments but has no resolver - what happens to those arguments?

## The mechanics first Arguments and resolvers are two separate stages of executing one field, and it is easy to assume the first implies the second. Stage one is entirely the spec's: for the field being executed, execution coerces the argument values. It matches the arguments written in the document (or supplied through variables) against the argument definitions on the schema's field, applies defaults for arguments the client omitted, coerces each value to its declared input type, and raises a request error if a Non-Null argument is missing or a value cannot be coerced. This happens whether or not anything will ever look at the result. Stage two hands those coerced values to the field's resolver. And when no resolver was registered, the generic default one runs — the rule that reads a member of the same name off the parent value. It gets the arguments. It ignores them. So the arguments are **fully validated and completely inert**. The client's request is well-formed, the response is a normal 200-shaped success with no errors list, and the field returns the parent's whole same-named member as though no argument had been written. ## The failure, in a seat-map graph An airline seat-map service exposes an append-only log of seat-inventory changes per aircraft, and the schema declares it with a filter: ```graphql type SeatMap { aircraftRegistration: String! seatEvents(since: DateTime, limit: Int = 100): [SeatEvent!]! } ``` The parent value is a loaded seat-map aggregate that happens to carry a `seatEvents` collection, so default resolution finds a same-named member and returns it. In development that collection holds a couple of dozen entries and every test passes: the client sends `since` and gets back events, and nobody notices that the events it got back were not filtered. In production the list grew without a bound. Eighteen months of reconfigurations, crew blocks and irregular-operations churn later, one long-lived widebody's aggregate carried 41,830 events, and every client asking for "changes in the last hour" was serialising all of them. The symptom was not a wrong answer that anyone could see — clients were rendering the most recent entries and discarding the rest — it was response size, serialisation time and memory pressure climbing on a curve nobody could tie to a code change. The `limit: 100` default made it worse: it read like a guarantee in the SDL, and it was never applied. ## Why it is hard to catch * **Nothing errors.** No validation failure, no field error, no log line. The argument was legal, so the request was legal. * **The SDL lies convincingly.** Reviewers read the field signature and infer behaviour. An argument in the schema is a promise, and the default resolver never made it. * **Small data hides it.** Any test fixture whose collection is smaller than the limit produces identical results filtered or not. The test asserts the events came back, not that filtering happened. * **Wiring is silent.** Most servers do not consider "field with arguments, no resolver" an error at startup; the default is the fallback for every field uniformly. An audit across a 62-subgraph supergraph found nine fields in this state — all of them list fields with a filter or a limit argument that no code consumed. Every one had been added by someone extending a schema next to fields the default was legitimately serving. ## Defences, in order of value 1. **A schema check in CI.** Walk the executable schema and fail the build for any field that declares arguments but has no registered resolver. It is a handful of lines against the built schema and it catches the class outright, not the instance. 2. **A test per argument, not per field.** The assertion that matters is *differential*: two calls with different argument values must return different results. Fixtures must be larger than the limit under test. 3. **Treat the default as a whitelist, not a fallback.** Some servers can be configured to require explicit resolvers, or to log unresolved fields at startup; where that exists, use it on list fields at minimum. 4. **Watch response size by operation.** Field-level metrics and payload-size percentiles per operation name will show the drift long before a user complains, because the failure signature is volume, not errors. ## The generalisation worth saying out loud An argument in a schema is documentation until code reads it. Default resolution serves the fields whose value is already sitting on the parent value, and a field that takes arguments is by definition not one of those: its value depends on something the client said. The moment you add an argument to a field, you have taken it out of the default's domain — and nothing in the type system will tell you so.