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.

[router-perf]

CI performance tests

• connectors-const - Connectors stress test that runs with a constant number of users
• 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
• 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:

• Add an option to limit number of errors returned sangria-graphql/sangria#1017
• Limit number of errors returned (when variables are used) sangria-graphql/sangria#1034