Use partition-aware preload for Vulnerabilities::Feedback
What does this MR do and why?
Opts Vulnerabilities::Feedback into the partition-aware pipeline preload framework so the vulnerability feedbacks finder and the finding dismissal-feedback lookup avoid a cross-partition scan of p_ci_pipelines.
Both pipeline-preloading scopes now chain with_partition_aware_preload:
with_associations(usesincludes) — consumed bySecurity::VulnerabilityFeedbacksFinder(REST).all_preloaded(usespreload) — consumed byVulnerabilities::Finding.dismissal_feedback.
When a page of feedback records is loaded, the preload_associations hook resolves the :pipeline association through Gitlab::Ci::Pipeline::BulkByIdLookup (partition-pruned) and hands the pipelines to ActiveRecord's Preloader via available_records:, so the pipeline lookup is pruned by partition_id instead of scanning all partitions. The sibling associations (issue, merge_request, author, comment_author, project) are still preloaded normally.
The override reads both preload_values and includes_values, so it intercepts the includes-based scope too (the finder does not call references, so includes stays in separate-query preload mode). No consumer changes are needed.
Part of #601100. The framework (with_partition_aware_preload / PipelineRelationPreload) and the partition_aware_pipeline_preload feature flag are already on master, so this is a focused, independently-mergeable scope swap.
Behavior
- FF on (
partition_aware_pipeline_preload): partition-pruned bulk pipeline lookup, no per-recordp_ci_pipelinesquery. - FF off: falls back to a vanilla bulk preload (still not N+1), by design.
How to set up and validate locally
Run the model + finder specs:
bundle exec rspec ee/spec/models/vulnerabilities/feedback_spec.rb \
ee/spec/finders/security/vulnerability_feedbacks_finder_spec.rbThe model spec asserts, for both with_associations and all_preloaded: pipeline bulk-loaded with no per-record p_ci_pipelines query, sibling associations still preloaded, partition pruning (partition_id in SQL) with a warm partition cache, and FF-off fallback.
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.