In GraphQL, why is relaxing an argument to nullable safe when relaxing an output field is not?

## The rule is about direction of flow, not about `!` The single sentence worth memorising is: *a nullability change is safe when it loosens the obligation on whichever side has already shipped code.* Because arguments flow client to server and output fields flow server to client, that one rule produces two opposite answers, and candidates who memorise the output answer alone get the input case exactly backwards. ```graphql # outputs: the client READS -> may narrow what arrives certificate: Certificate -> Certificate! # safe for clients certificate: Certificate! -> Certificate # breaks clients # arguments: the client WRITES -> may widen what is accepted enrollments(sectionId: ID!) -> (sectionId: ID) # safe for clients enrollments(sectionId: ID) -> (sectionId: ID!) # breaks clients ``` Relaxing `sectionId: ID!` to `sectionId: ID` cannot invalidate a document: every client that was already sending a section id may keep sending it, and the value it sends is still accepted. Tightening the other way rejects, at validation time, every document that omitted the argument — the operation never executes at all. Input object fields behave identically, because they are the same position one level down. ## The default-value wrinkle The symmetry is not quite clean, and the wrinkle is a favourite follow-up. Under the specification an argument or input field is *required* only when its type is Non-Null **and** it has no default value. So this is legal SDL and the argument is optional to supply: ```graphql type Query { enrollments(sectionId: ID!, limit: Int! = 25): [Enrollment!]! } ``` `limit` is Non-Null — a client may never pass an explicit `null` for it — yet a document that omits it is valid, because the default fills in. Two consequences follow. First, "Non-Null argument" and "required argument" are not synonyms, and a schema diff that conflates them will misclassify edits. Second, adding a default value to an existing Non-Null argument is itself a loosening: it turns a required argument into an optional one without changing the type. ## Type-safe is not semantically safe The direction rule tells you whether documents keep *validating*. It says nothing about what the server now does with an absent value, and that gap is where the real incidents live. A course-enrolment service had a viewer-scoped field: ```graphql type Query { enrollments(viewerId: ID!, sectionId: ID): [Enrollment!]! } ``` A refactor relaxed `viewerId: ID!` to `viewerId: ID`, correctly classified as a safe input loosening, so that internal callers could omit it and let the server infer the viewer from the session. Nothing broke at validation. But a response cache sitting in front of the endpoint keyed entries on the operation plus its variables, and once `viewerId` was omitted, two different signed-in learners produced byte-identical cache keys. The second learner was served the first learner's enrolment rows. The schema change was type-safe in every sense the direction rule cares about, and it still leaked data across viewers. The lesson is not that the direction rule is wrong; it is that it is narrower than it feels. Loosening an input makes a *new absence* possible, and every layer that derives meaning from the arguments — a cache key, an authorization decision, a rate-limit bucket, an audit record — now has to answer a question it never faced. Ask what absent will mean before you make absent legal. ## Explicit null versus omitted One more distinction sits underneath all of this. Relaxing an argument to nullable makes two new situations possible, not one: the client may *omit* it, and the client may pass an explicit `null`. Under a Non-Null argument both were rejected. After the change both are accepted, and a server that treats them identically has silently decided that "I did not say" and "I say nothing" mean the same thing. Whether that is right is a design decision the type alone does not make for you. ## Answering this in an interview State the rule as one principle rather than two memorised facts, demonstrate it in both positions, then volunteer the default-value wrinkle and one semantic consequence. That progression — principle, both directions, the exception, then the thing the rule does not cover — is what separates a senior answer from a recited one.