Why is a client-supplied operation name a risky GraphQL metric dimension?

## Where the operation name comes from It helps to be exact about the artefact. An executable document may name its operations — `query EmployeeBadge($id: ID!) { ... }` — and a request may also carry an `operationName` selecting which of them to run. That selection is required when the document defines more than one operation. Both halves are written by the caller. The server checks that the named operation exists in the document; it does not, and cannot, check that the name is *apt*. So when someone proposes labelling request metrics with the operation name, the honest description is: we are letting every caller in the world write directly into our metric label set. Two distinct failures follow, and a strong answer names both. ## Failure one: the label set is unbounded Metric dimensions are only useful when the number of distinct values is small and stable, because each combination of values creates and retains a series. A hand-written GraphQL client is well behaved here — a payroll and benefits app might have 137 named operations across its screens, and that set changes at release cadence. But nothing enforces that discipline, and the ways it breaks are mundane rather than malicious: * A build step appends a content hash to every operation name for cache-busting, so `PayslipList` becomes `PayslipList_a91f3c` and every release invents a full generation of new series. * A screen builds its document text by string interpolation and lets an identifier leak into the name. * A third-party integration, an internal script or an automated scanner sends arbitrary documents with arbitrary names. One real shape of this incident: a graph with 137 registered operations observed 19,412 distinct values on that label inside 72 hours. Nothing was under attack; a client had shipped per-render names. The cost lands somewhere unpleasant — the metric pipeline, the storage bill, query latency on every dashboard built over that metric — and, worse, the metric stops being useful long before it stops working, because no single series has enough traffic to have a baseline. ## Failure two: the label is unverified This one is subtler and is the part candidates usually miss. Even bounded, the name is a *claim*, not an observation. A document named `EmployeeBadge` may select an 8,400-row page of payslips and expand each one's deduction lines. The server will happily execute it and your metric will happily attribute several seconds and a large amount of backend work to the badge operation. The consequences are not only cosmetic. Every downstream use of that dimension inherits the lie: per-operation latency baselines, cost attribution to a team, an allowlist keyed by name, rate limits per operation, and any objective computed per operation. Someone probing the endpoint does not even need bad intent to cause it — a copied-and-edited document that kept the old name does the same damage. Treat the name as caller-controlled input, because it is. ## What to dimension by instead Rank the candidates by who produces them. **Operation type** — `query`, `mutation`, `subscription`. The server derives it by parsing the document, so it is authoritative, and it has exactly three values. Always safe, always worth having. **A server-computed document hash.** Hash the document *after* parsing and printing it back in a canonical form, so that whitespace and formatting differences collapse to one value. This is a fact about what actually ran and cannot be forged: change the selection and you change the hash. It is not automatically bounded — a client that interpolates literals into query text produces a new hash per request — but it converts an unbounded label into an observable property of your traffic, and a spike in distinct hashes is itself a useful signal. **A persisted document identifier.** Where documents are registered ahead of time, or exchanged for a hash through the Automatic Persisted Queries handshake, the identifier the server already keys on is the natural dimension, and the value set is exactly the set of documents you have accepted. This is the strongest option and it is one of the underrated reasons to adopt persisted documents at all. **The client-declared name, sanitised.** Keep it — it is the only human-readable handle and it is what an engineer will search for — but pass it through a bounded map: if the name is in the known set for that document, use it; otherwise emit a single literal `unknown`. Then `unknown` becomes a first-class signal. A sudden rise in it means a new client, a broken build, or someone poking at the endpoint, and it costs you exactly one series to detect. A good final answer is a pairing: hash for identity, sanitised name for legibility, and the honest sentence that the name never travels alone.