fix(graphql): skip Apollo health checks in Mercurius#9363
Conversation
Apollo Gateway reaches the Mercurius request boundary before the graphql-js hooks, so each poll still emitted a graphql.request span after its nested spans were suppressed. Match the same exact fixed query at that boundary so health-check-shaped user operations remain traced.
Overall package sizeSelf size: 6.77 MB Dependency sizes| name | version | self size | total size | |------|---------|-----------|------------| | import-in-the-middle | 3.3.1 | 122.62 kB | 438.86 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | dc-polyfill | 0.1.11 | 25.74 kB | 25.74 kB |🤖 This report was automatically generated by heaviest-objects-in-the-universe |
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 37764f3 | Docs | Datadog PR Page | Give us feedback! |
BenchmarksBenchmark execution time: 2026-07-15 00:31:44 Comparing candidate commit 37764f3 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 2316 metrics, 42 unstable metrics.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #9363 +/- ##
=======================================
Coverage 96.64% 96.64%
=======================================
Files 923 923
Lines 122844 122875 +31
Branches 20989 21059 +70
=======================================
+ Hits 118723 118756 +33
+ Misses 4121 4119 -2 Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
pabloerhard
left a comment
There was a problem hiding this comment.
Just curious on why is this not an option? Is it always considered as noisy?
|
@pabloerhard I can not imagine any customer wanting the health checks from being traces. That is indeed very noisy and would likely be a magnitude higher than all other spans of a customer combined. I would only ever imagine allowing this as option, if it is requested and I can not imagine that. Adding options for something that will almost with certainty never change is not a good idea. Options are adding complexity and mental overhead for us and the customer. |
Apollo Gateway reaches the Mercurius request boundary before the graphql-js hooks, so each poll still emitted a graphql.request span after its nested spans were suppressed. Match the same exact fixed query at that boundary so health-check-shaped user operations remain traced.
Apollo Gateway reaches the Mercurius request boundary before the graphql-js hooks, so each poll still emitted a graphql.request span after its nested spans were suppressed. Match the same exact fixed query at that boundary so health-check-shaped user operations remain traced.
Apollo Gateway reaches the Mercurius request boundary before the graphql-js hooks, so each poll still emitted a graphql.request span after its nested spans were suppressed. Match the same exact fixed query at that boundary so health-check-shaped user operations remain traced.
Apollo Gateway reaches the Mercurius request boundary before the graphql-js hooks, so each poll still emitted a graphql.request span after its nested spans were suppressed. Match the same exact fixed query at that boundary so health-check-shaped user operations remain traced.
Summary
Apollo Gateway health-check polls still emitted a
graphql.requestspan for Mercurius because its request boundary runs before the graphql-js hooks. Skip the same exact fixed query at that boundary, while keeping similarly named user operations traced.Refs: #9134