Limit the amount of GraphQL validation errors returned in the response

[goto-bus-stop]

A small proposal.

It's possible to craft relatively small queries (within a few dozen KB) that produce tens of thousands of validations errors. The router then needs to spend a bunch of time formatting several megabytes of JSON in response. That's a waste of time.

By limiting the amount of errors we limit the response size and the time spent formatting the response to those queries.

I only applied it to GraphQL parsing and validation errors here. Perhaps it should be a general limit in the router. But for parsing and validation errors I think it's reasonable to silently drop further errors--I'm not sure it's appropriate for every other kind of error.

[svc-apollo-docs]

✅ Docs Preview Ready

No new or changed pages found.

[github-actions[bot]]

@goto-bus-stop, please consider creating a changeset entry in /.changesets/. These instructions describe the process and tooling.

[router-perf[bot]]

CI performance tests

• [ ] connectors-const - Connectors stress test that runs with a constant number of users
• [x] const - Basic stress test that runs with a constant number of users
• [ ] demand-control-instrumented - A copy of the step test, but with demand control monitoring and metrics enabled
• [ ] demand-control-uninstrumented - A copy of the step test, but with demand control monitoring enabled
• [ ] enhanced-signature - Enhanced signature enabled
• [ ] events - Stress test for events with a lot of users and deduplication ENABLED
• [ ] events_big_cap_high_rate - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity
• [ ] events_big_cap_high_rate_callback - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity using callback mode
• [ ] events_callback - Stress test for events with a lot of users and deduplication ENABLED in callback mode
• [ ] events_without_dedup - Stress test for events with a lot of users and deduplication DISABLED
• [ ] events_without_dedup_callback - Stress test for events with a lot of users and deduplication DISABLED using callback mode
• [ ] extended-reference-mode - Extended reference mode enabled
• [ ] large-request - Stress test with a 1 MB request payload
• [ ] no-tracing - Basic stress test, no tracing
• [ ] reload - Reload test over a long period of time at a constant rate of users
• [ ] step-jemalloc-tuning - Clone of the basic stress test for jemalloc tuning
• [ ] step-local-metrics - Field stats that are generated from the router rather than FTV1
• [ ] step-with-prometheus - A copy of the step test with the Prometheus metrics exporter enabled
• [x] step - Basic stress test that steps up the number of users over time
• [ ] xlarge-request - Stress test with 10 MB request payload
• [ ] xxlarge-request - Stress test with 100 MB request payload

[yanns]

This is a good idea. We did that in the sangria library as well for example:

• https://github.com/sangria-graphql/sangria/pull/1017
• https://github.com/sangria-graphql/sangria/pull/1034