How do you make a GraphQL list field require at least one selective filter argument?

## The incident this question comes from A farm sensor graph exposes `sensorReadings(filter: SensorReadingFilter, orderBy: SensorReadingOrder)`. Every field on the filter is nullable, because that is what optional means, so `sensorReadings(orderBy: { field: RECORDED_AT })` with no filter at all is a valid document. It matches every reading ever recorded, and the service ends up sorting an 8,400-row result per request to return the first page of it, several times a minute, from a dashboard nobody remembers building. The obvious fix was shipped in a deploy: tighten `SensorReadingFilter.stationId` from `ID` to `ID!`, so a caller must always name a station. Every saved dashboard document that filtered only by a date range stopped validating the moment the schema rolled out — on an input field, requiring something that used to be optional is the breaking direction, and it breaks at validation time for everyone at once, not gradually. ## What the type system can and cannot express It can express **always required**: a non-null argument or a non-null input field with no default. That is an unconditional obligation on every caller, which is exactly what broke the dashboards. It cannot express **at least one of these**. There is no modifier for it, no directive in the specification for it, and no way to say "either `stationId` or a bounded `recordedAfter`/`recordedBefore` pair". The nearest thing in the ecosystem is the one-of input pattern, which is a specification *draft* and expresses **exactly one** field — mutual exclusivity, not a minimum — so it does not solve this even when it is available. So the question is not "which modifier do I use". It is "which of four real options do I pick, knowing the schema cannot state the rule". ## Option 1 — model the access paths as separate fields Instead of one general field with a hopeful filter, publish the queries you can actually serve: ```graphql type Query { readingsByStation(stationId: ID!, recordedAfter: DateTime, recordedBefore: DateTime): [SensorReading!]! readingsByMetricWindow(metric: MetricKind!, recordedAfter: DateTime!, recordedBefore: DateTime!): [SensorReading!]! } ``` Now the type system does enforce it, because each field's anchor is genuinely non-null on every call. The cost is surface area: two fields where there was one, and a third when a new access path appears. This is the honest option, and on a graph with two or three real access patterns it is usually right. ## Option 2 — require an anchor argument on the one field Keep `sensorReadings` and lift the anchor out of the filter input into a required argument of its own: `sensorReadings(stationId: ID!, filter: SensorReadingFilter, orderBy: SensorReadingOrder)`. This works only when every legitimate caller really does have a station in hand. Introduce it on a **new** field, or from day one; converting the existing field is the same breaking change that started the incident. ## Option 3 — validate at execution and say so Leave the filter fields nullable and have the field reject an under-specified call with a clear, coded error and a message that names the acceptable combinations. This is the pragmatic fallback and it is often what ships. Be honest about its cost in an interview: the rule is now invisible to introspection, a typed client generator cannot enforce it, and callers only learn about it at runtime. Anything enforced here belongs in the field's description as well, because the description is the only place a reader can find it. ## Option 4 — bound the damage instead of requiring the predicate Sometimes the real requirement is not "filter something" but "do not let one call cost this much". Page-size limits and static cost scoring attack that directly and are separate mechanisms with their own designs; they are worth naming as the alternative framing, because a required predicate is a poor proxy for a cost bound — a caller can supply `stationId` for the busiest station and still be expensive. ## How to choose Ask whether the under-specified call is *illegitimate* or merely *expensive*. If it is illegitimate — nobody should ever ask for all readings — the schema should say so structurally, which means options 1 or 2, introduced as new fields rather than tightened onto old ones. If it is legitimate but costly, do not lie about it in the type system: allow it and bound it. And whichever you choose, do not fix it by tightening nullability on a filter field that clients are already omitting. That is a validation-time break for every existing document, delivered by a deploy, with no gradual signal beforehand.