fix(tracemetrics): Parse units off response in events request#109608
fix(tracemetrics): Parse units off response in events request#109608narsaynorath wants to merge 1 commit intomasterfrom
Conversation
We need to do this because the old alerts UI uses this EventsRequest component. For metrics, we're starting to surface the units properly from the backend which means that the old ways of inferring it from the aggregate do not work anymore. This allows the charts in the alerts UI to properly display metrics in the correct units while also allowing fallbacks to the old way if the response doesn't have data. The response will take precedence.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| timeseriesResultsUnits?.[aggregate] as RateUnit | ||
| ) | ||
| ? (timeseriesResultsUnits?.[aggregate] as RateUnit) | ||
| : undefined; |
There was a problem hiding this comment.
Size metrics double-converted causing inflated display values
High Severity
transformTimeseriesData in eventsRequest.tsx already scales size values to bytes (e.g., kibibyte values multiplied by 1024). The new code then passes the original unit (e.g., "kibibyte") from timeseriesResultsUnits to tooltipFormatter and axisLabelFormatterUsingAggregateOutputType, which both call convertSize(value, 'kibibyte', BYTE) — treating the already-in-bytes value as kibibytes and multiplying by 1024 again. This causes size metric chart tooltips and axis labels to display values inflated by the unit's scale factor.


We need to do this because the old alerts UI uses this EventsRequest component. For metrics, we're starting to surface the units properly from the backend which means that the old ways of inferring it from the aggregate do not work anymore. This allows the charts in the alerts UI to properly display metrics in the correct units while also allowing fallbacks to the old way if the response doesn't have data. The response will take precedence.
This follows a similar pattern we're applying for dashboards at the moment. Essentially we construct
timeseriesResultsUnitsandtimeseriesResultsTypeswhich are used in conjunction to propagate the types and units from the metadata of the response. Then we update the areas that deal with this kind of data for formatted to prioritize the object if it exists.