GeezerVison

Problem

TwitterBenchmark builds a query that is 150 levels deep. Since e4c287c ("Add query depth and field count limits to Validator") validation enforces QueryComplexityLimits with a default maxDepth of 100, so every benchmark execution fails with:

MaxQueryDepthExceeded: Query depth 101 exceeds maximum allowed depth 100

and returns data == null. Because the benchmark uses a persisted query cache, it has been measuring the return of a cached validation error (~8M ops/s) rather than execution, and those numbers flow into the performance results history.

Fix

• Pass a QueryComplexityLimits with maxDepth(DEPTH + 1) through the request's GraphQLContext (QueryComplexityLimits.KEY) rather than changing the global default, so other benchmarks in the same JVM are unaffected.
• Execute the query once during class initialisation and fail fast if it returns errors, so the benchmark cannot silently degrade into measuring an error path again.

Verification

• Before: query returns MaxQueryDepthExceeded, data == null; benchmark reports ~8,090,000 ops/s.
• After: query returns no errors and fully nested data (150 levels, 150 leaves at the bottom); benchmark reports 359 ± 12 ops/s (~2.8 ms per ~22.6k field query, Apple Silicon, JDK 21).
• Temporarily lowering the limit to DEPTH - 1 makes class initialisation throw ExceptionInInitializerError, confirming the fail-fast check works.
• graphql.archunit.* tests pass (JMH fork rule).

Note: the historical TwitterBenchmark numbers recorded since the limits were introduced are not comparable with results after this change.