Summary

Fixes #3868.

This implements the merged spec change from graphql/graphql-spec#860: subscription root selections must not use @skip or @include. This aligns GraphQL Java with graphql-js graphql/graphql-js#3974.

Why this is different from the reverted implementation

The previous GraphQL Java implementation in #3871 was reverted by #3917 because it tried to coerce variables during validation and then used the execution FieldCollector. That made validation depend on runtime-style variable handling, and it failed when validation did not have the complete execution input variables available.

This implementation avoids that problem by not evaluating @skip or @include for this validation rule. It also does not introduce a separate subscription-only document traversal. Instead, OperationValidator now reuses its existing operation-scoped traversal and fragment retraversal, the same path already used for operation-scoped rules such as variable usage, defer validation, and complexity tracking.

The rule keeps small operation-local state while the existing traversal runs:

• depth-1 subscription fields are collected as root fields
• root-level @skip / @include directive AST nodes are collected syntactically
• fragment definitions are interpreted from each operation spread site using the existing fragment retraversal context
• fragment summaries are cached only to cover the existing optimization where a fragment already visited elsewhere in the operation is not traversed again

There is no ValuesResolver.coerceVariableValues call, no empty runtime variable map passed into execution collection, no execution FieldCollector, and no custom conditional runtime decision involved.

That matches the reason the spec changed: validation must be able to determine subscription root fields without access to runtime variable values. It also catches cases the reverted implementation could miss, such as @skip(if: true) or @include(if: false) on root subscription selections.

Tests

Added Spock coverage for:

• root subscription fields with @skip / @include using variables
• literal @skip(if: true), @skip(if: false), @include(if: true), and @include(if: false)
• one validation error containing both directive locations when both directives appear at the subscription root
• anonymous subscriptions
• root fragment spreads and inline fragments
• root fields reached through fragments
• recursive fragments
• cached fragment-summary behavior when a fragment is first traversed below a root field and later spread at the subscription root
• subfield directives remaining valid
• query and mutation root directives remaining valid
• aliased introspection root field validation
• interface and union type-condition cases for subscription root inline fragments

Added JMH coverage for:

• complex subscription validation with many root fragments and nested fragments
• existing general validation benchmark harness now returns validation results instead of discarding them and no longer depends on execution success during setup

Local verification:

• ./gradlew test --tests graphql.validation.SubscriptionUniqueRootFieldTest --tests graphql.execution.MergedSelectionSetTest
• ./gradlew test --tests 'graphql.validation.*' --tests graphql.execution.MergedSelectionSetTest
• ./gradlew jmhClasses test --tests graphql.archunit.JMHForkArchRuleTest

Local JMH Comparison

Ran on the same machine with JDK 25.0.2:

• java -jar build/libs/*-jmh.jar -wi 2 -i 5 -w 2s -r 2s -f 1 -rf json -rff /tmp/graphql-java-pr-validation-jmh.json 'benchmark.(ValidatorBenchmark|SubscriptionValidationBenchmark).*'
• same command against origin/master in a temporary worktree with only the JMH benchmark patch applied

Results, ms/op lower is better:

Repeated the subscription benchmark with more samples:

• java -jar build/libs/*-jmh.jar -wi 3 -i 8 -w 2s -r 2s -f 2 -rf json -rff /tmp/graphql-java-pr-subscription-jmh.json 'benchmark.SubscriptionValidationBenchmark.complexSubscription'

Interpretation: I do not see a general validation regression in the large-schema and many-fragment validation benchmarks. The synthetic complex subscription benchmark shows a small, measurable cost of about 0.010 ms/op for the new rule logic, which is the expected cost of tracking subscription root selections syntactically during the existing validation traversal instead of using execution field collection.