ref(issues): Batch requests for non-error groups

[saponifi3d]

Description

Update the _prepare_params_for_category to be a batch method. Instead of producing filters such as:

occurrence_type_id IN (DB_QUERY_TYPES)
occurrence_type_id IN (HTTP_CLIENT_TYPES)
occurrence_type_id IN (MOBILE_TYPES)

it produces one union:

occurrence_type_id IN (
    DB_QUERY_TYPES,
    HTTP_CLIENT_TYPES,
    MOBILE_TYPES,
    ...
)

Allowing us to make 1 query for errors, and 1 query for all other types; where previously we had 7 total concurrent queries.

Uses organizations:issue-search-merged-generic-query as a feature flag to safely rollout the changes.

Dashboard to monitor impact and rollout

[saponifi3d]

@cursor review this pr

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

[saponifi3d]

don't love how much this is changing vs what's happening today; the tl;dr is that it's just building a reference dict that can be used the same way as we do today or batch the generic categories. 🤔

[kcons]

Mostly educating myself, since I don't know this code. It looks pretty reasonable, I need to look a bit more to feel confident.

[kcons]

why do we reverse for multiple categories?

[saponifi3d]

The merged query needs to match the downstream SequencePaginator, which sorts (score, group_id) with reverse=True; equal-score rows are therefore consumed by descending group_id. Once multiple categories share one Snuba LIMIT/OFFSET, fetching ties in ascending ID order would select the opposite end of the tie block and can skip or repeat rows across pages. The singleton path stays ascending to preserve the existing behavior (and EAP comparison) while the feature flag is off. The conditional is non-obvious, but the pagination test exercises it.

[kcons]

we only use issue platform if we're not searching for errors.. which means we can choose to use issue platform or not for other categories and we're okay making errors determine that vs using more queries?

[saponifi3d]

This is not choosing the dataset for a mixed error/generic query. Error is explicitly excluded from category merging above, and get_search_strategy asserts that ERROR cannot appear with generic categories. So the only inputs here are [ERROR], which uses Events, or one or more non-error categories, which use Issue Platform. Errors still get their own query and do not force other categories onto Events.

[kcons]

there may be an argument for factoring out a function that returns query_params_for_categories.

[saponifi3d]

I considered this, but _prepare_params_for_categories already owns construction of each SnubaQueryParams; extracting the full loop would mostly move the same long argument list into another method. The genuinely new part is building category_filter_groups, so that is the smaller extraction I would make if we want to shorten snuba_search further.

tl;dr, it felt important to keep this as focused fix to try and fix the N+1 issue; i think we could do quite a bit of cleanup work here.

[hobzcalvin]

no better type to be had here?

[saponifi3d]

i had actually refactored it to: list[tuple[list[GroupCategory], Sequence[SearchFilter]]] but that required a bunch of other changes -- needing to refactor a few other areas in this. i ended up reverting that diff because i wanted to keep the change focused to fixing the query problem.

can def bring that back if you feel strongly, was just trying to balance the number of changes outside of the rollout flag.