feat(configuration-issues): Making processing_errors queryable

[Abdkhan14]

Summary

Registers processing_errors as a queryable EAP dataset so the events and events-stats APIs can query processing error data (e.g. for issue details charts). Used established patterns for other queryable datasets as a guide.

• search/eap/processing_errors/ module with column, attribute and aggregate function definitions
• New ProcessingErrors RPC dataset class in snuba/processing_errors_rpc.py supporting table, timeseries, and top-events queries
• Registers the dataset in types.py, constants.py, utils.py and enables it in the organization_events and organization_events_stats endpoints (including top-events support)
• Exposes attribute mappings via the attribute mappings API
• Adds ProcessingErrorTestCase mixin with helpers to create and store processing error items

Test Plan

• tests/sentry/search/eap/test_processing_errors.py — validates query parsing (filters, negation, in-filter, AND/OR, empty)
• tests/snuba/api/endpoints/test_organization_events_stats_processing_errors.py — validates count, zerofill, top events grouped by error_type, filtering, and empty top events

[github-actions]

Backend Test Failures

Failures on d51fdb9 in this run:

tests/sentry/api/endpoints/test_organization_attribute_mappings.py::OrganizationAttributeMappingsEndpointTest::test_get_all_mappings — log

tests/sentry/api/endpoints/test_organization_attribute_mappings.py:34: in test_get_all_mappings
    assert types_present == expected_types
E   AssertionError: assert {'logs', 'occ...metrics', ...} == {'logs', 'occ...time_results'}
E     
E     Extra items in the left set:
E     'processing_errors'
E     
E     Full diff:
E       {
E           'logs',
E           'occurrences',
E     +     'processing_errors',
E           'profiles',
E           'spans',
E           'tracemetrics',
E           'uptime_results',
E       }

[Abdkhan14]

@wedamija I've added a todo for the received attr from #109851. Will follow up when your pr is merged.

[cursor]

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

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

• ✅ Fixed: Parameter additional_queries silently dropped in table query
  • ProcessingErrors.run_table_query now forwards additional_queries into rpc_dataset_common.TableQuery, so caller-provided additional filters are no longer dropped.

Or push these changes by commenting:

@cursor push b11c4835be

Preview (b11c4835be)

diff --git a/src/sentry/snuba/processing_errors_rpc.py b/src/sentry/snuba/processing_errors_rpc.py
--- a/src/sentry/snuba/processing_errors_rpc.py
+++ b/src/sentry/snuba/processing_errors_rpc.py
@@ -46,6 +46,7 @@
                 sampling_mode=sampling_mode,
                 resolver=search_resolver or cls.get_resolver(params, config),
                 page_token=page_token,
+                additional_queries=additional_queries,
             ),
             params.debug,
         )

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

[cursor]

Parameter additional_queries silently dropped in table query

Low Severity

ProcessingErrors.run_table_query accepts additional_queries as a parameter but never passes it to the TableQuery constructor. This means any cross-trace query filters provided by callers are silently ignored. The majority of other RPC datasets (Spans, OurLogs, TraceMetrics, PreprodSize) forward additional_queries to the TableQuery. While cross-trace queries may not be needed for processing errors today, silently dropping a caller-provided parameter can lead to confusing behavior if it's ever relied upon.

 

[Abdkhan14]

Working on this

[sentry]

Bug: The run_table_query method for ProcessingErrors accepts additional_queries but fails to pass it to the TableQuery constructor, causing cross-trace filters to be silently ignored.
_{Severity: MEDIUM}

Suggested Fix

In the run_table_query method, pass the additional_queries parameter to the TableQuery constructor. The call should be updated to include additional_queries=additional_queries to ensure cross-trace filters are applied correctly.

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/snuba/processing_errors_rpc.py#L37-L50

Potential issue: In `src/sentry/snuba/processing_errors_rpc.py`, the `run_table_query`
method accepts an `additional_queries` parameter but does not pass it to the
`TableQuery` constructor. This parameter is used to apply cross-trace filters from API
parameters like `spanQuery` or `logQuery`. Because it is omitted, any such filters
provided by a user for the ProcessingErrors dataset are silently ignored. This results
in the query returning unfiltered data, which is incorrect and does not match the user's
request. Other datasets correctly pass this parameter, indicating this is an omission.

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

[Abdkhan14]

Working on this.