Why must fragment spreads in a GraphQL document never form a cycle?

## A spread is expansion, not a call The mental model that makes the cycle rule obvious is this: spreading a fragment is not invoking a function that returns a value. It is *including that fragment's selection set at the point of the spread*. When a server collects the fields for a selection set, it walks the selections, and every time it meets `...SomeFragment` it substitutes that fragment's own selections and keeps walking. There is no call stack, no return, and no notion of "the same fragment, one level down". Now put two fragments in a payroll and benefits graph that reference each other: ```graphql fragment EmployeeCore on Employee { fullName manager { ...ManagerSummary } } fragment ManagerSummary on Employee { fullName directReports { ...EmployeeCore } } ``` Expanding `...EmployeeCore` requires expanding `...ManagerSummary`, which requires expanding `...EmployeeCore`, and so on. The document text is finite and perfectly well formed, but the selection set it *denotes* is infinite. There is no natural place to stop, because the document never says how deep the org chart goes. ## The rule The specification therefore states a validation rule of its own: the fragment spreads in a document must not form a cycle. It covers the direct case — a fragment that spreads itself — and every indirect chain, however long. Read the fragment definitions as a directed graph, with an edge from each fragment to every fragment it spreads anywhere inside itself, including inside nested selections and inline fragments. If that graph has a cycle, the document is invalid and the request fails before execution begins: no resolver runs, and the response carries errors with no data key. Notice what the rule is *not*. It is not a depth limit, not a size cap, and not a runtime safeguard that stops after so many expansions. It is a structural property of the document, decidable from the document alone, and it is checked once in the same static pass that checks field names and required arguments. ## Recursive types are legal; recursive fragments are not This is the distinction that separates a candidate who has thought about it from one who has memorised a rule. A GraphQL schema may be thoroughly cyclic: ```graphql type Employee { fullName: String! manager: Employee directReports: [Employee!]! } ``` That is not merely allowed, it is ordinary — most real graphs are cyclic, which is why they are called graphs. The type-level cycle is harmless because a *document* must write out every level it wants explicitly. A client that needs three levels of management chain writes three nested selection sets, and the document's own text bounds the depth. Fragments break that bound: a cycle would let a finite amount of text denote an unbounded selection, so the rule closes it at the document level while leaving the schema free. ## The neighbouring hygiene rules The cycle rule sits with two siblings that come from the same instinct — a document should say exactly what it means and nothing else. A spread must name a fragment that is actually defined in the same document. There is no import mechanism in the language; whatever a client's tooling does to assemble fragments from separate source files, what arrives on the wire must be one self-contained document, and a spread whose target is absent fails validation. And every fragment defined in the document must be spread at least once. A definition nobody uses is dead weight the server would parse and hold for no reason, and far more often it is the fingerprint of a bug: a client assembled a document from several sources and dropped the selection that was supposed to use the fragment. Rejecting it turns a silent mistake into an immediate, located error. ## Diagnosing one in practice Cycles rarely get written by hand. They appear when fragments are composed by tooling or by convention — one fragment per screen area, each pulling in the next — and two of them end up mutually referential through a relationship such as `manager` and `directReports`. The symptom is unmistakable once you know the rule: the failure is total, immediate and identical on every request carrying that document, with an errors list and no data key, and it reproduces with no data in the system at all. That last property is the tell. Anything that fails identically against an empty database is a static problem, and the fix is in the document rather than in a resolver: break the loop by writing the levels you actually need explicitly, and keep each fragment's spreads acyclic.