feat(dynamic-sampling): add EAP based query for retrieving transaction volumes

[constantinius]

Closes https://linear.app/getsentry/issue/TET-2306/create-transaction-volume-query-for-eap

[linear-code]

TET-2306 Create transaction volume query for EAP

[shellmayr]

I'm not sure why we need this - we don't seem to do anything with the results AFAICT?

[constantinius]

They are mapped to the equivalence of ProjectTransactions: total_num_transactions and
total_num_classes

[shellmayr]

I think if you rebase, you'll get this from master

[github-actions]

🚨 Warning: This pull request contains Frontend and Backend changes!

It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently.

Have questions? Please ask in the #discuss-dev-infra channel.

[sentry]

Bug: The logarithmic scale bucketing logic incorrectly calculates the first bucket's lower bound when min_value is not zero, causing data points near the minimum to be excluded.
_{Severity: MEDIUM}

Suggested Fix

Revise the formula for calculating bucket boundaries in a logarithmic scale. Instead of adding an offset to the min_value, the calculation should correctly map the logarithmic range to the data's actual range, ensuring the first bucket starts at min_value.

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: src/sentry/api/endpoints/organization_events_heatmap.py#L177-L183

Potential issue: The formula for calculating logarithmic bucket boundaries, `lower_bound
= bucket_ranges.min_value + y_log_scale ** (current_bucket * bucket_size)`, is flawed.
When `current_bucket` is 0, the lower bound becomes `min_value + 1`. This incorrectly
excludes any data points that fall within the range `[min_value, min_value + 1)`. This
issue only manifests when the queried data has a minimum value greater than zero and a
logarithmic scale is used, as existing tests only cover cases with a minimum of zero.

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

[sentry]

Bug: When max_transactions is hit, get_eap_transaction_volumes returns a partial sum for total_num_transactions, violating the expected contract and causing incorrect sampling rate calculations.
_{Severity: MEDIUM}

Suggested Fix

When the max_transactions limit is reached and the loop terminates early, the function should set total_num_transactions to None instead of returning a partial sum. This correctly signals to downstream consumers that the total is unknown, preserving the established data contract.

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: src/sentry/dynamic_sampling/per_org/tasks/queries.py#L157-L186

Potential issue: The `get_eap_transaction_volumes` function can return a partial sum for
`total_num_transactions` when the `max_transactions` limit is reached. The downstream
`TransactionsRebalancingModel` expects `total_num_transactions` to be either the true
total for the project or `None` if the total is unknown. Providing a partial sum as if
it were the true total will cause the model to perform budget calculations with an
incorrect, underestimated total, leading to inaccurate dynamic sampling rates for the
project.

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

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

^{Reviewed by Cursor Bugbot for commit 165e4e6. Configure here.}

[cursor]

Log scale base 0 silently accepted without validation

Low Severity

The yLogScale parameter validation rejects base 1 (ParseError) but accepts base 0, which is also mathematically undefined. When yLogScale=0 is passed, y_log_scale is set to 0, use_log_scale evaluates to False (since bool(0) is False), and the endpoint silently falls back to linear scale. A user explicitly requesting log scale with base 0 gets no error, unlike base 1 which is properly rejected. The validation at y_log_scale == 1 needs a companion check for y_log_scale <= 0 (or < 2 depending on desired minimum base).

 

^{Reviewed by Cursor Bugbot for commit 165e4e6. Configure here.}