What does a per-operation timeout on a GraphQL server bound that a cost limit cannot?

## Two different questions about one operation Every abuse control on a GraphQL endpoint answers exactly one of two questions, and confusing them is the mistake this topic exists to correct. The first question is **how big is this request?** Depth caps, field-count caps, body-size caps and complexity scores all answer it. They are computed from two artefacts the server holds before it runs anything: the executable document the client sent, and the schema. Walk the selection set, add up per-field weights, multiply where a list-slice argument such as `first` tells you a subtree repeats, compare the total against a budget, reject if it is over. This is *static analysis of a document*. It is fast, deterministic, and it happens before a single resolver is called. The second question is **how long did this request take?** Nothing in the first category can answer it, because the answer does not live in the document. It lives in the data, in the caches, and in whatever the downstream systems are doing at that moment. ## Why a small document can be slow Consider a warehouse inventory graph with a valuation field: ```graphql query WarehouseValuation($warehouseId: ID!) { warehouse(id: $warehouseId) { name stockValuation } } ``` Two fields, one nesting level. Any depth cap passes it. A cost limiter that weights object fields at 1 scores it at 2 or 3. And `stockValuation` may sum across 8,700 bins, join a pricing table, and take four seconds. The score was not *wrong* — the document really is small. It simply measured the wrong dimension. Three independent sources of that gap: **Data volume the document does not mention.** The same document run against a warehouse holding 12 bins and one holding 8,700 has the same score and wildly different runtimes. **Variables.** Static scoring uses the variable *values* only when they are literal slice arguments the limiter knows how to read. An identifier, a date range, a filter object — all of these change the work enormously and none of them change the score. **Environment.** This is why the classic symptom is a query that times out only in production. A staging dataset seeded with a few dozen rows makes every resolver instant; production has the real cardinality, a cold cache after a deploy, a lock held by a batch job, or a downstream service answering at three times its usual latency. The document did not change. The clock did. ## What a deadline actually is A per-operation deadline is a wall-clock budget attached to the operation at the moment it starts executing, carried through the execution as part of the per-request context, and honoured by the code that waits on anything. When it expires the server stops waiting for the outstanding work and produces whatever answer it can. It is worth being precise that this is **not in the GraphQL specification**. The specification defines parsing, validation and an execution algorithm; it has no notion of elapsed time, no timeout error, no cancellation. Deadlines, like cost limits, are entirely a server-side convention. That matters in an interview because candidates routinely say "the spec requires" about controls the spec has never mentioned. ## Deadlines come in layers A real service usually has three, and they must nest: * A **transport-level timeout** on the HTTP request or the socket, the outermost backstop. * A **per-operation deadline** inside execution, the one this topic is about, which knows it is running a GraphQL operation and can therefore produce a GraphQL-shaped answer. * A **per-call timeout** on each downstream call a resolver makes, so one slow dependency cannot consume the whole operation budget. The inner budgets must be strictly smaller than the outer ones. If a downstream call is allowed 5 seconds while the operation deadline is 2 seconds, the operation deadline fires first and the downstream timeout never does anything useful. A sensible starting point is to derive the deadline from the latency budget you have already committed to. If a page has a 340 ms p99 budget, an operation still running at two or three seconds is not going to produce a useful answer for anyone — the user has navigated away, the caller's own client has probably given up. The deadline is not the target; it is the point past which the answer is worthless and holding resources for it is pure loss. ## What a deadline does not do It does not stop the backend work by itself — that requires cancellation to propagate into the resolvers and their drivers, which is a separate problem. It does not stop a caller from sending the same expensive operation a thousand times; that is what rate limiting and per-caller cost budgets are for. And it is the wrong tool for a subscription, which is *designed* to run indefinitely: a subscription needs limits on how many streams exist and how long an authorization lasts, not a deadline on the stream itself.