GraphQL 2024.1: Transition to Complexity-Based Query Rejection to Reduce Alert Noise

Goal: Reduce Alert Noise via Complexity-Based Rejection

The primary objective is to shift from execution-time monitoring to pre-execution query complexity analysis in GraphQL servers. By assigning numerical costs to fields and rejecting operations that exceed a configurable threshold, we aim to prevent resource exhaustion events that currently trigger excessive alerts.

Key constraints include accurately weighting dynamic arguments—such as pagination limits—that are not captured by static cost tables. Misconfigured weights can either let expensive queries slip through or block legitimate traffic, both of which undermine the alerting strategy.

Additionally, depth limiting must be calibrated to avoid breaking deeply nested client queries used by dashboards while still guarding against recursive attacks.

Unresolved behavior: How can we reliably incorporate dynamic argument costs into the complexity model without manual tuning?

Specific questions:

• What is the most effective strategy to weight dynamic pagination arguments in a complexity score?
• How can we balance depth limits with legitimate deeply nested queries used by dashboards?
• What tooling can help automatically generate accurate cost models for dynamic arguments?