In a GraphQL schema, what may a client send for a nullable input field that a Non-Null one forbids?

## The modifier binds the caller here, not the server The same `!` that promises a caller a non-null value on an output field does the opposite job on an input position. On a field argument, an input object field or a variable definition, Non-Null is a **requirement the client must satisfy**, and it is enforced during validation and input coercion — before a single resolver runs. That timing matters. A violated Non-Null input is not a field that failed while executing; it is an operation that never executed. The request is rejected as invalid, so nothing partial comes back and no side effect fires. ## Three states, and the one that disappears A nullable input field has three states a client can put it in, and they are genuinely distinguishable: 1. **Absent** — the field does not appear in the argument or input object at all. 2. **Explicitly null** — the field appears, carrying the literal `null` (directly, or through a variable whose supplied value is null). 3. **Present with a value.** The specification's input coercion keeps the first two apart: a field that is not provided and has no default is simply *not present* in the coerced input value, while a field provided as null *is* present with the value null. A server can therefore tell "the caller said nothing about this" from "the caller said: nothing". Mark that field Non-Null and state 2 vanishes outright — null is not among the values of a Non-Null type, so it can never be sent — and state 1 becomes a validation error unless the field or argument declares a default value. With a default, `first: Int! = 25` may be omitted (the default supplies the value) but may still never be given null. The result is that a Non-Null input field is effectively single-state from the caller's point of view: supply a value. ## Why anyone cares: clearing a value Take a job-board graph with an update mutation `updateJobPosting(id: ID!, patch: JobPostingPatch!)`, where `JobPostingPatch` declares `title: String`, `salaryMax: Int` and `requiredSkillIds: [ID!]`. A posting that has been advertising a ceiling of 96,400 now wants no published maximum. Because `salaryMax` is nullable, the client can send `"salaryMax": null` and the server can distinguish that from a patch that never mentioned `salaryMax`, applying it as "clear the value" while leaving unmentioned fields alone. Declare it `salaryMax: Int!` instead and that operation becomes inexpressible: the caller can raise or lower the ceiling but can never remove it, because the only way to say "no value" — null — is forbidden by the type. Two honesty points belong in the answer here. First, **"absent means leave it, null means clear it" is a convention, not something the specification defines.** What the specification guarantees is only that the two arrive distinguishably; what they *mean* is the server's decision and must be documented, because a caller cannot read it off the schema. Second, some servers and generated clients flatten absent and null into the same in-memory representation, at which point the distinction the specification preserved on the wire is lost inside the implementation — which is exactly the kind of thing to check before designing a patch mutation around it. ## Lists multiply the states The same reasoning applies one layer deeper on a list-typed input. An argument declared `skills: [String!]` on a `jobPostings` field has four caller-visible states: absent (no skill filter at all), explicit null (which the server may treat the same as absent, or not — again, its choice), an empty list `[]` (which reads naturally as "match nothing", or as "no filter", depending on whose code you read), and a populated list. This is precisely where filter arguments acquire surprising behaviour, and the fix is rarely a type change — it is deciding and documenting what each state means, and, where the ambiguity is not worth carrying, removing a state by making the argument Non-Null with a default. ## What a strong answer sounds like Say the direction of obligation first — on input, `!` binds the caller. Then count the states: three when nullable, one when Non-Null, with a default turning omission back into a legal move without ever admitting null. Then name where it is checked: validation and coercion, before execution, so the whole operation is rejected. Then give the concrete consequence: a Non-Null input field cannot express "clear this", which is why patch-style inputs keep their fields nullable. Finish by flagging the convention boundary — the specification separates absent from null, but the meaning you assign to each is yours to define and document.