Add optional maxDepth and maxAliases execution options

[eddieran]

Summary

Fixes #4662 — the execution engine has no built-in depth or complexity limits, allowing deep recursive queries and alias-bombing to cause denial-of-service via resolver amplification.

This PR adds two opt-in execution options:

• maxDepth — limits the field nesting depth during execution. When a field at depth > maxDepth is encountered, a GraphQLError is raised and the parent field resolves to null (standard nullable error handling). List indices do not count toward depth.

• maxAliases — limits the number of response keys (including aliases) per selection set. This prevents alias-bombing attacks where thousands of aliases for the same field bypass depth-based defenses. When exceeded, a GraphQLError is raised before the selection set executes.

Both options are undefined by default — no limits are applied and existing behavior is fully preserved. They are passed via ExecutionArgs.options alongside the existing maxCoercionErrors:

const result = await execute({
  schema,
  document,
  options: {
    maxDepth: 10,
    maxAliases: 50,
  },
});

Implementation details

• Depth checking happens in executeField by walking the Path linked list (only counting string keys, not list indices)
• Alias counting happens in executeOperation (root fields) and completeObjectValue (sub-selections) after field collection
• Errors follow standard GraphQL error propagation — nullable parent fields are nulled, non-null fields propagate upward
• 12 new tests covering: within-limit queries, exceeded limits, no-op when unset, list index handling, nested alias limits, combined usage

Test plan

• All 12 new tests pass
• Full test suite (1972 tests) passes with no regressions
• TypeScript compilation clean
• ESLint clean

[linux-foundation-easycla]

• ❌ - login: @eddieran / name: eddie . The commit (43e0e57) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.
• ❌ - login: @eddieran / name: Ran . The commit (f9d67dc) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[vercel]

@eddieran is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[yaacovCR]

Maybe we could consider adding a fieldDepth property to FieldDetails of type number? Then we wouldn't have to keep recalculating the path length?

[eddieran]

Thanks for the review, @yaacovCR! Since FieldDetails doesn't exist in the 16.x.x branch this PR targets (collected fields are plain Map<string, ReadonlyArray<FieldNode>>), I took the equivalent approach: thread a depth: number parameter through executeFields/executeField/completeValue and its helpers. completeObjectValue increments depth when descending into sub-selections; list items and abstract-type resolution keep the same depth as their parent field.

This turns the depth check into O(1) per field resolution instead of O(depth) walk of the Path linked list, while preserving identical semantics (list indices still don't count).

All 12 new tests and the full 1972-test suite still pass. Pushed in f9d67dc. Happy to take further suggestions, e.g. if you'd prefer a different naming or placement.