Fixed validation, planning and execution time growing quadratically and exponentially

[xperiandri]

Stacked on parser-dos-fixes, which is stacked on validation-dos-fixes; review those first. This PR has four commits: the last three fix what two rounds of adversarial review found.

Problem

Within the limits of the first PR (25 000 selections, nesting 128), some paths were still super-linear:

• Exponential:
  • planning fields under interfaces and unions; { node { child { … } } } nested 30 deep never finished;
  • merging such selections, including when @defer(if: $var) disables fragments;
  • QueryWeightMiddleware and ObjectListFilterMiddleware, which walked plans as trees;
  • the field merging rule.
• Quadratic:
  • planning many fields, spreads or deferred fragments;
  • executing an object with many fields;
  • the operation name uniqueness, unused variable and spread rules.
• Multiplicative:
  • the input value rule checked the values of a fragment for every operation spreading it: a 387 KB document took 71 s;
  • disabled deferred fragments were merged again for every object of a list.
• Never finishing: query ($a: Int = $a) made the input value rule loop forever.

Changes

• Planning:
  • reuses the plan of a selection set for the same field, return type and includer;
  • merges the plans of a field selected more than once all at once, remembered by the plans merged;
  • collects fields through an index by identifier.
• Execution inlines the fragments a variable disables once per request and selection set.
• QueryWeightMiddleware measures each shared plan once, as its total weight and the peak of the running sum, so it makes the same decisions and reports the same weights as before.
• ObjectListFilterMiddleware walks each plan once per path of response names, with interned paths. It now:
  • reports the filters of every list field, instead of only the last one;
  • keeps the first filter of a path that is filtered differently under different types, instead of failing; this is the same result as a tree walk;
  • no longer throws on a root @defer.
• Validation:
  • field merging compares each unordered pair once, as graphql-js's PairSet does, so it reports each conflict once;
  • the input value rule checks each value once per document and its variables once per operation, never follows a variable inside a default value, and stops at the error limit;
  • a new rule reports a variable in a default value;
  • the operation name uniqueness, unused variable and spread rules are linear.
• Breaking: SelectionInfoContext.FragmentDefinitions is replaced by Fragments, a dictionary by name.

Tests

The tests are xUnit, in ValidationDoSTests.fs, PlanningDoSTests.fs and MiddlewareTests.fs. Each runs on a 1 MiB stack with a 10 s timeout.

Case	f9077f98	This PR
Planning fields nested 30 deep under an interface	never finishes	ms
Middlewares on fields nested 25 deep	exponential	< 1 s
Planning 100 000 aliases or 50 000 deferred fragments	quadratic	< 1.5 s
12 000 operations spreading a fragment with a 4 000-integer list	71.2 s	1.9 s
2 000 operations spreading 2 000 invalid values	8.3 s	0.13 s
query Q($a: Int = $a) { … }	never finishes	ms
1 000 list objects with two disabled deferred fragments of 2 000 fields	timeout	1.5 s

• Behaviour tests: each behaviour fix has a test that fails with the previous code.
• Independent review: a reviewer ran differential fuzzers against f9077f98, with 8 800 documents for planning and execution and 8 000 for validation. The results were identical apart from the changes above.
• Unit tests: the whole project passes, 849 tests with 5 skipped as before. No existing expectation changed.
• FAKE: the full pipeline passes.

Left for later

Each of these predates this PR:

• Planning:
  • planning throws when a field is selected twice and both selections hold a deferred fragment, since both are numbered @defer#0;
  • a field selected twice under one name, with and without a field-level @defer, @stream or @live, cannot be merged;
  • { node { id } node { __typename } } loses its second selection;
  • an inline fragment without a type condition inside ... on A applies to every type.
• Validation:
  • the merging rule skips the selection set of a field selected once;
  • the input value rule checks root fields only.
• Other:
  • LINQ tracking still walks plans as trees;
  • a token limit comes with the new parser.

Stacked PRs get no CI run, because the workflow only runs for PRs into master and dev.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Field merging misses nonadjacent conflicts, and list filters inside deferred fragments are omitted.

2 open findings

• Check all unordered field pairs, not only adjacent pairs · New
• Preserve deferred fragment field filters in metadata · New

What changed in this PR

Optimizes validation, planning, execution, and middleware traversal to prevent super-linear behavior and denial-of-service risks.

Changes:

• Adds shared-plan caching and efficient field merging.
• Makes validation rules linear or bounded.
• Adds adversarial performance and behavior tests.

File	Description
ValidationDoSTests.fs	Adds validation regression tests.
PlanningDoSTests.fs	Adds planning, execution, and middleware stress tests.
MiddlewareTests.fs	Tests multiple filter metadata entries.
FSharp.Data.GraphQL.Tests.fsproj	Includes the new test file.
Validation.fs	Optimizes validation traversals and lookups.
Planning.fs	Introduces plan reuse and indexed merging.
Execution.fs	Caches request-level deferred-fragment inlining.
MiddlewareDefinitions.fs	Optimizes middleware plan traversal.
RELEASE_NOTES.md	Documents fixes and breaking changes.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.