Giters

DataDog / dd-trace-js

JavaScript APM Tracer

Home Page:https://docs.datadoghq.com/tracing/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

data for 'graphql.execute' no longer recorded after updating to node 20

kuritz opened this issue · comments

commented

Expected behaviour
There should be no difference in recording of trace data for the graphql.execute operation when updating node versions.

Actual behaviour
Trace volume for our express server express.serve is unchanged, but the operation graphql.execute has a dramatic decrease in executions.

Screenshot 2023-12-11 at 3 29 32 PM

Steps to reproduce
I'm not sure what would be helpful in this case. the only thing changing is the node version from 18.18.2 to 20.10.0.

Environment

  • Operation system: debian bullseye
  • Node.js version: 20.10.0
  • Tracer version: 4.18.0
  • Agent version: 7.48.1
  • Relevant library versions:
  • graphql: 16.8.1
commented

This also occurred when we attempted to upgrade the tracer to the latest v4 minor. Support was able to help us identify that the 'operation' name is changing to the names of individual graphql queries/mutations. If graphql were its own service, with the ability to show those in a summary view, that would be fine. But since graphql was changed into an operation in v3, we now currently dont have a summary view in the APM showing the breakdown of our graphql api if we make this upgrade and each query/mutation becomes its own operation.

What is the best way to proceed?

commented

So, a couple of things here:

  1. I looked into our Node 20 upgrade, it turns out that we accidentally bumped the version of dd_trace at the same time, so I don't think it's the Node version that's the problem.
  2. When this originally happened, it was an update from dd_trace 4.18.0 to 4.20.0. I scrutinized all of the commits that happened and found that there was a PR that updated the open telemetry span names but also changed the way the format function works by mapping the operation.name to the name tag when calling extractTags. See 55ab6f5#diff-f09b1f948eecfaec88ebb77d4af63d6a3a9e4c56112746246c6a48ad57814effR87

I then spun up our API server locally and printed out values for GraphQL spans after the formatting had been done. Indeed, the name of the span went from 'graphql.execute' to the GraphQL operation's name (e.g. 'UserDetails').

@Qard @tlhunter This seems like it was a breaking change in a minor version update. Do you have any more context as to why this change was made? What can we do to get back the previous behavior or to get summary information about graphql hits on our API server?

commented

And I looked through our code just now ... turns out that we're actually the ones setting the operation.name as a custom tag on the span ourselves, using a custom hook for the execute part of the GraphQL tracing. I tested removing those tags and it works again for us ... plus there's already a graphql.operation.name tag on the span that I'm guessing already comes built into the graphql plugin.

So, I think this issue can be closed and we can fix this on our side.

commented

And I looked through our code just now ... turns out that we're actually the ones setting the operation.name as a custom tag on the span ourselves, using a custom hook for the execute part of the GraphQL tracing.

Good find @strmer15 , that is interesting. I guess to close the loop on this, setting that tag did not override the operation.name value in previous versions, but upgrading changed the behavior of setting that tag.

I'm not sure this should be closed unless that change in behavior was desired?