## Current state `Search::AdvancedFinders::Sbom::DependenciesFinder` does not forward `security_project_tracked_context_id` or `tracked_refs_scope`. `FORWARDED_PARAMS` covers `component_ids`, `component_names`, `component_versions`, `licenses`, `malware`, `package_managers`, plus `not_component_versions` and `source_types`, and carries a `TODO` noting tracked refs are skipped as `::Sbom::DependenciesFinder` skips them. Both filters already exist in `Search::Elastic::SbomOccurrenceRefFilters` and are wired into `SbomOccurrenceRefQueryBuilder`, so nothing feeds them. `by_tracked_refs_scope` therefore always falls through to `is_default: true`, and the finder returns default-branch dependencies only. That is consistent today because `Sbom::OccurrenceRefsFilterable::ADVANCED_FILTERS` is `%i[malware]`, so a request only reaches Elasticsearch when `malware` is requested — and `Security::MalwareTrackedRefsValidation` rejects `malware` combined with `ALL_REFS` or a non-default `trackedRefIds`. ## Why forwarding them alone is not enough The `sbom_occurrence_refs` index holds one document per *(occurrence, tracked ref)*. `by_security_project_tracked_context_id` is a `terms` filter, so selecting two refs matches two documents for the same occurrence, and `ALL_REFS` matches one per ref. `Search::Elastic::ResponseMapper#records` hydrates through `Sbom::Occurrence.id_in`, which de-duplicates. The result is silent rather than loud: - a page of 20 hits becomes fewer than 20 rows - `Gitlab::Graphql::Pagination::ElasticConnection` derives `hasNextPage` from `paginated_items.length > limit_value` on that de-duplicated count, so "next" under-reports - when an occurrence's documents straddle a page boundary it renders on two consecutive pages, since de-duplication is per response, not across pages ## Proposal 1. Re-add a `collapse` component to `Search::Elastic::Formats` and wire it into `SbomOccurrenceRefQueryBuilder`. 1. Pass `collapse_field: :sbom_occurrence_id` from the finder, so Elasticsearch returns one hit per occurrence regardless of how many refs match. 1. Add `security_project_tracked_context_id` to `FORWARDED_PARAMS` and map `tracked_refs_scope` (symbolised, as `by_tracked_refs_scope` compares against `:all_refs`). 1. Restore the invariant comment on `SbomOccurrenceRefSorts::SORT_FIELDS`: every entry must be occurrence-level. All eight currently are. 1. Decide routing. `ADVANCED_FILTERS` is `%i[malware]` and `advanced_filters_available?` gates on `malicious_packages_dependency_list_filtering`. If tracked-ref filters should route to Elasticsearch on their own, that gate needs separating — the malware flag is the wrong condition for them. `collapse` is compatible with `Search::Elastic::Pagination`: Elasticsearch forbids `collapse` with `search_after`, and `Pagination` uses none — it emits `sort`, `size` and a `bool.filter` range clause. ## Keep `sbom_occurrence_id` as the tie breaker Collapse returns exactly one hit per distinct `sbom_occurrence_id`, so the value is unique among returned hits **by construction** — not by convention. And because the collapse field *is* the tie breaker, `sbom_occurrence_id > cursor` excludes every document of the cursor's occurrence, so a collapse group cannot straddle a page boundary. This supersedes https://gitlab.com/gitlab-org/gitlab/-/issues/626775, which proposed indexing `sbom_occurrence_ref_id` to use as the tie breaker instead. A unique ref-id tie breaker fixes drop/repeat but not the short pages or the cross-page duplicate, because two documents of one occurrence still get *different* sort tuples. Close 626775 if this lands. It also resolves https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251780#note_3762995075, where duplicate default tracked contexts per project were flagged as making `sbom_occurrence_id` non-unique. Nothing enforces one default context per project — the unique index covers `(project_id, context_name, context_type)`, not `is_default`, and there is no model validation. ## Unchanged `Security::MalwareTrackedRefsValidation` stays. It rejects `malware` with non-default refs because malware advisory scanning only runs against the default branch, so the answer would not describe the requested ref. That is a data constraint, not a fan-out one, and collapse does not relax it. ## Caveats - **`hits.total` counts documents, not groups**, so `Search::Elastic::Relation#size` over-reports under collapse. Harmless today: `Types::Sbom::DependencyType.connection_type` exposes no `count` field, and `ElasticConnection` never reads `hits.total`. - **`tracked_refs_count`** is `object.occurrence_refs.size`, a Postgres count of *all* refs, so it is filter-independent and will not reflect the selected subset. Matches current behaviour. - **Divergence from Postgres.** `::Sbom::DependenciesFinder` ignores tracked-ref params entirely, so today a caller passing `trackedRefIds` gets an unfiltered list. The Elasticsearch path would honour them, which is a fix but a visible change in behaviour depending on which backend serves the request. ## Testing - multiple `trackedRefIds` return one row per occurrence, and a full page - `trackedRefsScope: ALL_REFS` returns one row per occurrence - a project with **two default tracked contexts** paginates without dropping or repeating a row — the case the current fixtures miss - a multi-ref occurrence sitting exactly on a page boundary is neither repeated on nor skipped past the next page - forward and backward walks across every sort with several refs selected