Some GraphQL queries sent over GET fail with an HTTP error and no response body — how do you diagnose it?

## The signature: a failure that tracks size, not operation The tell in this failure is a mismatch between two vantage points. At the edge — a load balancer's access log, a CDN report, the browser's network panel — the requests exist and carry a 4xx status. In the GraphQL server's own operation metrics and logs, they do not exist at all. No parse, no validation error, no resolver, no timing. Traffic that is visible to HTTP and invisible to GraphQL means the request was rejected before execution, and on a GET the overwhelmingly common reason is that the URL was too long for some hop to accept. The second tell is *which* requests fail. A bug in an operation fails that operation every time. A length ceiling fails whichever requests happen to cross it, so failures cluster by variable payload rather than by operation name — the same query succeeding for one caller and failing for another is the shape to look for. ## Where the ceiling actually lives Nothing specifies a maximum URL length. What exists is a stack of independent limits, any one of which can be the binding one: - **The browser or client runtime**, which will refuse or truncate beyond its own bound. You do not control it and cannot configure it for your users. - **Every intermediary**: CDN, reverse proxy, load balancer, API gateway. These typically cap the request line and the total header block, with configurable defaults commonly in the 4-8 KB range. - **The server's own HTTP layer**, with its own request-line and header-buffer limits, applied before your application code runs. The status you get back depends on which hop refuses. **414 URI Too Long** is the purpose-built answer; many intermediaries answer 400 instead, and a limit hit on the header block rather than the request line can surface as 431. Because the refusal is generated by an intermediary, the body is that hop's error page — never a GraphQL envelope. A client that assumes otherwise reports a JSON parse failure, which is why this often reaches you as "the API returns garbage" rather than "the URL is too long". Remember also that percent-encoding inflates the payload roughly threefold for every escaped character, so the encoded length you must fit is far larger than the document you wrote. ## Diagnosing it, in order 1. **Correlate with size, not with operation.** Pull the failing request lines and measure their length. If the failures start above a threshold and there are no failures below it, you are done hypothesising. 2. **Find the exact threshold.** Replay one operation from a shell client, growing a list variable an element at a time. A clean binary cutover — every request under *n* bytes succeeds, every request over it fails — is conclusive, and the number usually lands on a recognisable configured value. 3. **Walk the hops.** Send the oversized request straight at the origin, bypassing the edge, then at each layer in turn. The first hop that rejects it owns the limit. Its access log will show the request; the next hop's will not. ## The red herring worth naming On a translation-memory graph running to a 1,200-request-per-minute peak, roughly 3.1% of GET reads began failing with no server-side trace. The failures clustered almost entirely on senior editors, which pointed the first day of investigation at authorization — specifically the theory that a permission check ran too late in the pipeline and was blowing up after the response had been assembled. It was not. Senior editors were simply the accounts with many project scopes, and the client passed those scopes as a list variable: 47 identifiers of about 40 characters each, which pushed the encoded URL past an 8,192-byte limit on one proxy tier. The correlation with privilege was real and entirely incidental. The lesson generalises — when a failure correlates with a user attribute, check whether that attribute also correlates with request *size* before believing it is about permissions. ## Fixes, in the order worth trying **Shorten the URL.** Replace the document text with a persisted operation identifier; that removes the largest and most variable component and leaves the variables as the only thing that can grow. **Bound the variables.** A list variable with no cap is an unbounded URL. Page it, or take a filter identifier instead of an inline list. **Fall back to POST for that operation.** Legitimate, and safe because the operation is a read, but you pay a round trip if you discover the limit by getting rejected, and the response loses its shared-cache eligibility — which was the entire reason for using GET. **Raise the limit.** Possible at hops you own, and useless unless you raise it at *every* hop, including ones you may not own. The browser's limit is not yours at all, so this can never be the whole answer. ## Keeping it from returning Put the guard on the client, where the length is known before the request leaves: compute the encoded URL, and if it exceeds a configured budget comfortably under the tightest hop, send that one operation over POST instead of discovering the ceiling from a 414. Back it with a check in the build that fails when a persisted operation's encoded form exceeds the budget, and an alert on the 414 and 431 rate at the edge, since by construction those never appear in application-level error metrics.