fix(aci): set failure rate y-axis range based on seriesMax and threshold

[ameliahsu]

we were hardcoding the y-axis max to be 100%, which makes it difficult to see small percentages. this change sets the max to the max between the seriesMax and the specified threshold.

before

after

[scttcper]

make sure to check crash free session rate. this is the reason it was locked to 100% Showing over 100 isn't interesting and also makes deviations from 100% -> 99.5% crash rate hard to see.

[ameliahsu]

@scttcper fixed, had to pass aggregate to useDetectorChartAxisBounds so we can know if it's a percentage

[sentry]

Bug: The normalizePercentageThreshold function doesn't divide failure_rate() thresholds by 100, but the UI shows a '%' suffix. This causes user-entered percentages to be saved as values 100x too large.
_{Severity: CRITICAL}

🔍 Detailed Analysis

The normalizePercentageThreshold() function in useMetricDetectorThresholdSeries.tsx incorrectly handles thresholds for failure_rate(). While the UI displays a '%' suffix, prompting users to enter whole numbers (e.g., 5 for 5%), the function does not normalize this input by dividing by 100. It only performs this normalization for session-based operations. Consequently, a user-entered value like 5 is stored as 5.0 instead of the expected 0.05. Since the backend expects failure_rate() data on a 0-1 scale, this results in an alert threshold that is 100 times larger than intended (e.g., 500% instead of 5%), making it practically impossible for the alert to ever trigger.

💡 Suggested Fix

Update the normalizePercentageThreshold() function to also divide the threshold value by 100 for failure_rate(). This can be achieved by modifying the condition that checks for percentage operations to include failure_rate(), ensuring its value is correctly scaled from a user-entered percentage to a decimal representation (0-1) before being sent to the backend.

🤖 Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location:
static/app/views/detectors/hooks/useMetricDetectorThresholdSeries.tsx#L105-L117

Potential issue: The `normalizePercentageThreshold()` function in
`useMetricDetectorThresholdSeries.tsx` incorrectly handles thresholds for
`failure_rate()`. While the UI displays a '%' suffix, prompting users to enter whole
numbers (e.g., `5` for 5%), the function does not normalize this input by dividing by
100. It only performs this normalization for session-based operations. Consequently, a
user-entered value like `5` is stored as `5.0` instead of the expected `0.05`. Since the
backend expects `failure_rate()` data on a 0-1 scale, this results in an alert threshold
that is 100 times larger than intended (e.g., 500% instead of 5%), making it practically
impossible for the alert to ever trigger.

_{Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 8370020}

[ameliahsu]

Need to remove the % in the UI, will do in a separate PR

[cursor]

Percent detection thresholds incorrectly normalized for session metrics

High Severity

The normalizePercentageThreshold function is applied to ALL thresholds in extractThresholdsFromConditions, including those for percent detection type. However, percent detection thresholds represent a percentage change (e.g., "5% higher than comparison"), not an absolute percentage value. For session percentage operations like crash_free_rate, the threshold (e.g., 5) gets incorrectly divided by 100 to become 0.05. This causes createPercentThresholdSeries to calculate the wrong multiplier (1 + 0.05/100 = 1.0005 instead of 1 + 5/100 = 1.05), making threshold lines nearly invisible. The series name also displays "0.05% Higher Threshold" instead of "5% Higher Threshold".

🔬 Verification Test

Why verification test was not possible: This is a React hook that requires the full Sentry frontend environment with Jest and React testing utilities. The bug is identified through static code analysis tracing the data flow:

1. extractThresholdsFromConditions now normalizes ALL thresholds via normalizePercentageThreshold
2. For session ops like crash_free_rate, a 5% threshold becomes 0.05
3. In percent detection type, createPercentThresholdSeries calculates multiplier as 1 + thresholdPercentage / 100
4. With normalized value: 1 + 0.05/100 = 1.0005 (nearly no change)
5. Expected without normalization: 1 + 5/100 = 1.05 (5% increase)

The old code applied division by 100 only in the static detection handling, not for percent detection.

Additional Locations (1)

• static/app/views/detectors/hooks/useMetricDetectorThresholdSeries.tsx#L195-L199

 

[ameliahsu]

I don't think this is valid because we don't allow percent change for crash_free_rate 🧐