GeezerVison

Spock, MaxQueryDepthInstrumentation(6) on {f1: foo {...F} f2: foo {foo {foo {foo {...F}}}} } fragment F on Foo {foo {foo {scalar}}}, before the change:

MaxQueryDepthInstrumentationTest > throws exception if too deep through a fragment that was spread before FAILED
    Expected exception of type 'graphql.execution.AbortExecutionException', but no exception was thrown

the query is 7 deep. written inline it is rejected with maximum query depth exceeded 7 > 6.

QueryTraverser follows a spread by handing the shared FragmentDefinition node to graphql.util.Traverser, which enters a node only once and treats later encounters as back references. every spread of a fragment after the first is skipped together with the fields under it, even when it sits under a different parent field (#1695). MaxQueryComplexityInstrumentation, MaxQueryDepthInstrumentation and FieldValidationInstrumentation all run on QueryTraverser, so a client can put the expensive part of a query behind a fragment it spreads more than once and have it neither counted nor validated. with the default 1 + childComplexity calculator:

17 KB query, 1000 aliases each spreading one 20 field fragment
before: complexity 1040
after:  complexity 41000 (the fields actually requested)

NodeVisitorWithTypeTracking.visitFragmentDefinition now removes the fragment's nodes from the traverser's visited set when the definition is left, so the next spread is followed again. a spread of a fragment inside its own body still finds it visited while it is being traversed, so fragment cycles still terminate (covered by a test). this is what the QueryTraverser javadoc already describes (no field merging), and it is the same per spread counting OperationValidator uses for its field count limit, which also bounds how far repeated spreads can expand.

one behaviour change to be aware of: scores go up for queries that reuse fragments. the standard introspection query goes from 64 to 191 with the default calculator (depth stays at 13), so a MaxQueryComplexityInstrumentation limit set between those two values will start rejecting it.

the new tests in QueryTraverserTest, MaxQueryDepthInstrumentationTest and MaxQueryComplexityInstrumentationTest fail before the change. the full test and testng suites pass on Java 25, and the analysis tests pass on 17 and 21.