perf(eap-items): Index-prune, dedupe, and sort sentry.timestamp on the raw column

[phacops]

EAP item queries put sentry.timestamp on the read path in three ways — as a range filter, as a redundant copy of the mandatory time-range bound, and as a sort key. All three went through attribute_key_to_expression, which maps sentry.timestamp to CAST(timestamp, <type>). Since timestamp is in the primary key (organization_id, project_id, item_type, timestamp) and the partition key toMonday(timestamp), the CAST defeats granule pruning, partition pruning, and optimize_read_in_order alike — showing up as one shard being consistently slow on skewed data.

Range filters compare the raw column

Range comparisons (<, <=, >, >=) on sentry.timestamp are now rewritten to target the raw DateTime column:

-- before
(CAST(timestamp, 'Float64') AS `sentry.timestamp_TYPE_DOUBLE`) >= 1781040732

-- after
timestamp >= toDateTime('2026-06-09 21:32:12')

The column is second-resolution DateTime, so CAST(timestamp, 'Float64') already yields whole seconds — comparing against toDateTime(value) is equivalent for the integer unix-second values clients send. EQUALS/IN and SELECTing sentry.timestamp (which must still return a number) keep the CAST path.

Dedupe of identical conditions

The rewrite reuses the same canonical toDateTime('YYYY-MM-DD HH:MM:SS') form as the mandatory time-range bound, so a client filter whose bounds equal the request window becomes a byte-identical expression. treeify_or_and_conditions now drops structurally-identical conjuncts from the top-level WHERE AND (A AND A == A) before re-nesting, collapsing those duplicates. Distinct ranges are left untouched — they're all rewritten to the raw column and kept, and the AND of them yields the tightest window. The pass is a no-op (no rebuild) when there are no duplicates.

Nothing downstream dedupes conditions (the ClickHouse formatter joins AND args verbatim), so this is the only place the duplicate gets removed. Because every RPC endpoint calls treeify_or_and_conditions, they all get both the raw-column rewrite (shared filter path) and the dedupe.

ORDER BY targets the raw column

sentry.timestamp sorts had the same problem. The trace-item-table resolver already expanded a first-position, single-project, no-group-by timestamp sort into the full table sort key for optimize_read_in_order, but every other timestamp sort (secondary sort key, alongside a group by, or across multiple projects) fell through to attribute_key_to_expression and ordered by CAST(timestamp, <type>). _convert_order_by now orders by the raw timestamp column for sentry.timestamp in that branch too. The cast is monotonic, so the result order is identical, but ClickHouse can read in primary-key order.

Tests

Tests build the query AST via build_query and assert on the generated WHERE/ORDER BY clauses (no live ClickHouse needed): equal ranges collapse to one bound, different ranges keep both, 3+ distinct bounds are all kept and never use a Float cast, and sentry.timestamp sorts emit the raw timestamp column rather than a CAST.

[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 2053538. Configure here.}

[cursor]

Fractional timestamp ranges truncated wrongly

Medium Severity

For sentry.timestamp range filters with val_float or val_double, the rewrite passes int(scalar_value) into timestamp_seconds_to_datetime_literal. Truncating toward zero changes the bound versus comparing CAST(timestamp, 'Float64') to the full float, so some rows match the old query but not the new one (and vice versa).

 

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

[sentry]

Bug: Timestamp filters with floating-point values are silently truncated to integers, losing sub-second precision and potentially altering query boundaries.
_{Severity: MEDIUM}

Suggested Fix

Consider either supporting sub-second precision by not casting to int, or add validation to reject or warn when a client sends a fractional timestamp. If truncation is the desired behavior, add a comment explaining why it is safe and intentional.

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: snuba/web/rpc/common/common.py#L354

Potential issue: When processing timestamp filters, floating-point values from
`val_float` or `val_double` are explicitly cast to integers using `int(scalar_value)`.
This truncates any sub-second precision from the timestamp. A client sending a filter
with a fractional timestamp, such as `sentry.timestamp >= 1781040732.7`, will have its
filter silently rewritten to use the truncated integer value, `1781040732`. This can
lead to unexpected query results, as the filter boundaries are shifted by up to one
second without any warning or error to the client.

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