-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to distinguish between dataloader fetched fields in datafetcher observations and offer dataloader instrumentation #1034
Comments
Thanks for reaching out. I had a look at our instrumentation and wrote a test case for this. We can consider several changes here and some of them are quite involved, so I have scheduled this for our next feature release. As far as I can see, it is completely transparent to a We can extend our We can also consider instrumenting We could, when the request execution starts, get the
We would then need to create a new context/convention/key-values set for this new |
For the route with |
Feature Request
Hi there - I am currently migrating from graphql-kickstart to spring-graphql. The new observations in the
GraphQlObservationInstrumentation
are really great!However I suffer from a huge amount of "noise spans" when using dataloaders, as the traces contain a Span for every resolved Child node (with an
graphql.field.path
in an array-like iteration/myfield/edges[x]
). That means for a GQL request with a 5000 page size, 5000 spans are added even though only one single database request happens in the end and this is the interesting part to investigate on the resulting trace.I'd propose that we can somehow recognize the "dataloaded fields" (e.g by attaching a
graphql.datafetcher.completeablefuture=true
KevValue
as an extra highCardinalityKeyValue for each observation; or something similar), then one would be able to filter them later. To make this complete, an Observation for all called dataloaders would be very helpful.The text was updated successfully, but these errors were encountered: