I'm not sure if this should be considered a bug or feature request, but given the consequences of this behaviour I'd consider this a bug.
At work we noticed that arrays in graphql inputs are reported as separate metric for each array index. This is surprising because it's not the case for arrays of returned fields, which are collapsed into one metric. As a result we've seen some of our queries which can accept thousands of inputs to produce thousands of different metric entries in Metric Explorer. I'm also concerned this might be causing us to hit cardinality metric limits in New Relic.
I'd expect metrics for input arrays to be collapsed similarly to how it's collected for returned field metrics.
For the given example above, I'd expect:
Description
I'm not sure if this should be considered a bug or feature request, but given the consequences of this behaviour I'd consider this a bug. At work we noticed that arrays in graphql inputs are reported as separate metric for each array index. This is surprising because it's not the case for arrays of returned fields, which are collapsed into one metric. As a result we've seen some of our queries which can accept thousands of inputs to produce thousands of different metric entries in Metric Explorer. I'm also concerned this might be causing us to hit cardinality metric limits in New Relic.
Example:
This query would report metrics:
Expected Behavior
I'd expect metrics for input arrays to be collapsed similarly to how it's collected for returned field metrics. For the given example above, I'd expect:
Alternatively it could be configurable, just like opentelemetry intrumentation does with
mergeItems
option: https://www.npmjs.com/package/@opentelemetry/instrumentation-graphqlTroubleshooting or NR Diag results
Steps to Reproduce
Your Environment
Node version: 20
Additional context