feat(eap): translate OP_REGEXP to ClickHouse match()

[pbhandari]

Problem

EAP RPC comparison filters have no regexp op. Logs search (LOGS-958) is blocked on EAP-739.

Depends on sentry-protos PR 420 (OP_REGEXP on ComparisonFilter / AnyAttributeFilter).

Solution

Translate OP_REGEXP in the shared EAP filter translator to ClickHouse match() (search-anywhere, RE2).

• Same type rules as LIKE (string and string-array keys)
• ignore_case → match(lower(value), lower(pattern))
• Empty pattern → 400
• ClickHouse CANNOT_COMPILE_REGEXP (36) remapped to RPC 400
• AnyAttribute op dispatch is a match including REGEXP

Validation

pytest tests/web/rpc/test_common.py::TestTraceItemFiltersRegexp and related LIKE/any-attribute tests.

Linear

https://linear.app/getsentry/issue/EAP-739/add-regexp-support-for-eap-rpc

[linear-code]

EAP-739

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

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

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

[cursor]

Ignore-case regex mangles escape sequences

Medium Severity

ignore_case applies lower() to the regexp pattern as well as the haystack. That is not equivalent to case-insensitive matching: RE2 escapes whose meaning depends on case (\S, \D, \W, \B, \Q, \A, \P) invert or break, so logs searches with ignore_case can silently return the wrong rows.

 

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

[pbhandari]

We can fix it when we upgrade our clickhouse to 26.8+ imo. This is fine as a stopgap solution.

[sentry]

Bug: The error message for unsupported operators in _any_attribute_op_expression uses the original filter_.op instead of the effective op, which could cause confusing error messages for future negative operators.
_{Severity: LOW}

Suggested Fix

Update the exception logging in the default case of the match statement to use the op parameter instead of filter_.op. Change f"Unsupported any_attribute_filter op: {AnyAttributeFilter.Op.Name(filter_.op)}" to f"Unsupported any_attribute_filter op: {AnyAttributeFilter.Op.Name(op)}". This ensures the error message accurately reflects the operator being processed by the function.

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#L905-L910

Potential issue: In the `_any_attribute_op_expression` function, the error handling for
unsupported operators incorrectly uses the original operator from the filter,
`filter_.op`, to generate the error message. The function logic, however, operates on an
`effective_op` (passed as the `op` parameter), which resolves negative operators (e.g.,
`OP_NOT_LIKE`) to their positive counterparts. If a new, unhandled operator is added in
the future that follows this negative-to-positive mapping, the resulting error message
will be misleading by referencing the original negative operator instead of the positive
one that was actually being processed.

[MeredithAnya]

@pbhandari is there more validation we can do here before we send the query to clickhouse (e.g. missing parentheses) ? Maybe doesn't have to be super robust but just anything that is guaranteed to fail we shouldn't send to clickhouse if possible