data for 'graphql.execute' no longer recorded after updating to node 20
kuritz opened this issue · comments
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.
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
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?
So, a couple of things here:
- 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. - 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 theformat
function works by mapping theoperation.name
to thename
tag when callingextractTags
. 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?
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.
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?