Are circular references between two object types legal in a GraphQL schema?

## Why a cycle is unremarkable In SDL, a field declares the **name** of its type, not its contents: ```graphql type Vehicle { id: ID! plate: String! currentDriver: Driver replacedBy: Vehicle } type Driver { id: ID! name: String! assignedVehicles: [Vehicle!]! } ``` Nothing here needs to be expanded or inlined, so nothing recurses at schema-build time. The schema is a graph of named types with edges between them, and a graph is allowed to have cycles — that is what makes it a graph rather than a tree. `Vehicle` pointing at `Driver` while `Driver` points back is normal; `Vehicle.replacedBy: Vehicle` — the unit that took over a decommissioned one's route — is a self-loop and equally normal. The question trips people up because they carry an intuition from data formats. A JSON document, a Protobuf message, an XML schema instance — those are trees, and a cyclic definition would suggest an infinite value. GraphQL avoids this by separating two things that other formats fuse: the **schema**, which is a graph and may cycle, and the **response**, which is a tree. ## What actually terminates execution The response is a tree because the caller's selection set is a tree. A caller may write: ```graphql query { vehicle(id: "v-7731") { plate currentDriver { name assignedVehicles { plate } } } } ``` and may keep going around the loop as many times as they care to type. What they cannot do is write an infinite document — a document is finite text, and execution walks exactly the fields it selects. There is no rule in the specification that stops a cycle, because none is needed for termination. This has an operational consequence rather than a correctness one: a caller *can* type a very deep traversal, and each level multiplies the work behind it, so servers exposed to untrusted callers apply limits on what a single request may ask for. Those limits are an operational control, not part of the type system, and they exist precisely because a cyclic schema makes a deep document easy to write. ## The one construct where the specification bans a cycle Input object types are the exception, and knowing it is what separates a curious answer from a memorised one. Because an input value must be fully supplied by the caller, an input object that contains itself through a chain of fields that are **all non-null and none of them lists** could never be given a value — every value would require another one beneath it, forever. The specification therefore requires that any such reference cycle be broken by at least one field in the chain being nullable or a list: ```graphql # invalid: the cycle is entirely non-null and non-list input RouteFilter { and: RouteFilter! } # valid: nullable breaks the chain input RouteFilterNullable { and: RouteFilterNullable } # valid: a list breaks the chain, since an empty list terminates it input RouteFilterList { all: [RouteFilterList!]! } ``` The list case is the one people get wrong: `[RouteFilterList!]!` looks non-null all the way down, but an empty list is a perfectly good value, so the recursion can bottom out. This rule is why recursive filter inputs are always written with nullable or list-typed combinators. For completeness, there is a second cycle ban elsewhere in the specification, and it is about documents rather than the type system: named fragments may not spread each other in a cycle, since a fragment spread really does substitute its contents and a cycle would have no finite expansion. ## The design question hiding behind the legality question Because cycles are free, schemas accumulate them by reflex: someone adds `Driver.assignedVehicles` because `Vehicle.currentDriver` exists and symmetry feels tidy. Symmetry is not a reason. A back- reference is a real field — it needs a resolver, an ordering, a nullability decision, and a bound if it returns a collection — and once published it is part of the contract whether anyone uses it or not. The useful test is whether a screen or a caller actually starts from the far side. In a fleet telematics graph, dispatch starts from the vehicle and wants the driver, so `Vehicle.currentDriver` earns its place. A driver's own app starts from the driver and wants today's vehicle, so the reverse edge earns its place too. A third edge added "for completeness" — every telemetry sample pointing back at its vehicle, which pointed at the sample list to begin with — buys nothing and gives callers one more way to write an expensive document.