fix(tracemetrics): Parse units off response in events request for alerts

[narsaynorath]

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 timeseriesResultsUnits and timeseriesResultsTypes which 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.

Resolves LOGS-585

[linear]

LOGS-585 Support units in old alerts page

[narsaynorath]

Decided to check for both here because the backend no longer requires us to send the aggregate alias, so this would allow both the alias and the raw series name to match.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Autofix Details

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Multi-series units lookup missing raw key fallback
  • Added fallback to check raw key when alias lookup fails, matching the pattern used in single-series path and transformTimeseriesData function.

Or push these changes by commenting:

@cursor push c9e50b7bdc

Preview (c9e50b7bdc)

diff --git a/static/app/components/charts/eventsRequest.tsx b/static/app/components/charts/eventsRequest.tsx
--- a/static/app/components/charts/eventsRequest.tsx
+++ b/static/app/components/charts/eventsRequest.tsx
@@ -556,7 +556,9 @@
         if (fieldsMeta) {
           timeseriesResultsTypes[key] = fieldsMeta;
         }
-        const unitsMeta = timeseriesData[key]!.meta?.units?.[alias];
+        const unitsMeta =
+          timeseriesData[key]!.meta?.units?.[alias] ??
+          timeseriesData[key]!.meta?.units?.[key];
         if (unitsMeta) {
           timeseriesResultsUnits[key] = unitsMeta as DataUnit;
         }

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

[cursor]

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.}

[cursor]

Axis label formatter missing sizeUnit parameter for size metrics

Medium Severity

The call to axisLabelFormatterUsingAggregateOutputType passes durationUnit and rateUnit but omits the sizeUnit parameter (7th argument). For size-type aggregates like p95(measurements.custom) with unit kibibyte, the formatter defaults to SizeUnit.BYTE, producing incorrect axis labels. The unit info is available in timeseriesResultsUnits but isn't extracted and forwarded like rateUnit and durationUnit are.

 

[narsaynorath]

This is okay. I agree this is weird but in the existing code we already normalized to bytes, so passing in the unit here would have doubled the normalization. I suppose we could get rid of the normalization but I wanted to avoid touching any of the existing behaviour to ensure this only applied for when unit was supplied which is only applicable to tracemetricnar/fix/tracemetrics-parse-units-off-response-in-events-request. Removing the normalization mean ensuring all of the existing code paths for other parts of the app reaching here needed to be checked properly too.