[lancefair431-code]

Summary

Fixes #360 by enforcing a configurable maximum query depth for the GraphQL endpoint.

Changes Made

• Add a configurable maximum GraphQL query depth.
• Validate query depth before resolver execution to prevent excessively nested queries from reaching application logic.
• Return a clear GraphQL error that includes both the configured maximum depth and the requested query depth.
• Handle introspection queries according to the documented depth-limit policy without creating an unrestricted bypass for ordinary queries.
• Document the query depth limit alongside the GraphQL schema and update .env.example if an environment variable is introduced.
• Add Vitest regression tests covering queries within and beyond the configured limit, error details, resolver execution, and relevant GraphQL query structures.

Testing

• Run the targeted GraphQL tests.
• Run npm test.
• Run the project's applicable lint and TypeScript checks.
• Verify that rejected queries do not execute resolvers.

Note: The existing Load test (prices) failure on the main branch is known. Any test failures should be reported accurately and distinguished from regressions introduced by this change.

Scope

This change is limited to GraphQL query-depth validation, its configuration, documentation, and tests. It does not modify pricing logic, financial behavior, or asset and contract identifiers.

Closes: #360

[drips-wave]

@lancefair431-code Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Miracle656]

Merged. #360 is yours and this is a careful piece of work — it closes the hole rather than appearing to.

The thing that makes it right is the part most depth limiters get wrong: fragments are expanded. Mercurius's built-in queryDepth doesn't, so a limit configured through it is defeated by moving the deep part of a query into a named fragment — the attack is one refactor away from the thing you're defending against. Counting a fragment node as adding no depth while its selected fields do is the correct accounting, and the test for it is the one I'd have asked for.

Four more details I checked and agreed with:

• Fragment cycles terminate. A fragment already being expanded isn't expanded again, so GraphQL's own cycle validation reports the cycle rather than this traversal blowing the stack first. Easy to get wrong in a recursive walk, and the test pins it.
• Introspection exempt only at the operation root. This is the second hole people leave: exempt __schema wholesale and an operation mixing __schema with deep application fields walks straight through. Checking depth === 0 and still measuring the application branch is the right narrow exemption, and again there's a test for the mixed case.
• A bad GRAPHQL_MAX_QUERY_DEPTH throws at startup. Most config parsing falls back to a default on garbage; here falling back would mean "no limit", so a deployment typo would silently undo a security control. Failing to boot is correct and the comment says so.
• Rejection in validation, before any resolver runs, with the error naming both the measured depth and the configured maximum — so a legitimate client that trips it can tell what to change.

One tradeoff worth flagging, not blocking

cache: false turns off Mercurius's document cache for every request, because a callback-style validationRules can't be used with it. You documented that, and choosing correctness over throughput on a security control is the right call — so I'm not asking you to change it. But it does mean every GraphQL request now re-parses and re-validates, and this is a public endpoint.

If you want the cache back later, there's a route that doesn't weaken anything: measure every operation in the document and take the maximum, rather than only the one operationName selects. That needs no callback, so a static validationRules array works and the cache stays on. It's strictly more conservative — the only behaviour change is that a multi-operation document carrying one deep unselected operation would be refused, which is a rare and arguably fine thing to refuse. Worth its own PR if GraphQL throughput ever matters; the repo has k6 load tests to tell you whether it does.

Also keep in mind DEFAULT_MAX_GRAPHQL_QUERY_DEPTH = 3 is pinned to "the deepest application selection in the current schema". Add a nested field to the schema and legitimate queries start failing until it's raised — that's the limit working, but it's a surprise worth remembering. A test asserting the default is greater than or equal to the schema's actual deepest path would turn that surprise into a red test.

Merge note: .env.example conflicted — #544's readiness-probe block landed while this was open. Resolved additively; both sections kept, and envDrift passes.

Verified on the merge result rather than your branch: tsc --noEmit silent, 896 tests across 83 suites, nothing red.

Closes #360.