Raise sec database health defer delay to 5 minutes

What does this MR do and why?

Changes delay_by from 1.minute to 5.minutes in the defer_on_database_health_signal declaration of two Sidekiq workers, plus the matching spec assertions. Four files touched, no other change:

• ee/app/workers/sbom/ingest_reports_worker.rb
• ee/app/workers/security/store_security_reports_by_project_worker.rb
• ee/spec/workers/sbom/ingest_reports_worker_spec.rb
• ee/spec/workers/security/store_security_reports_by_project_worker_spec.rb

No feature flag: this is a scheduling constant, and reverting is a one-line MR.

This was requested in review on both of the MRs that widened these workers' watched-table lists, and is the recommendation recorded in #629387:

• !255632 (merged) widened Sbom::IngestReportsWorker from 1 to 3 tables
• !255634 (merged) widened Security::StoreSecurityReportsByProjectWorker from 1 to 6 tables

AutovacuumActiveOnTable ORs the watched-table list, returning a Stop signal if autovacuum is running on any one of them. Widening the lists makes the stop signal fire more often. Gitlab::SidekiqMiddleware::SkipJobs has no maximum deferral count, so a job re-enqueues through Redis for as long as the signal holds, and on tables this size autovacuum can hold for hours. The exponential backoff that would cap the delay at 30 minutes sits behind incremental_database_health_defer_delay, which is gitlab_com_derisk and off by default, so today the re-enqueue interval stays flat at delay_by.

Simulation over 20,000 jobs with uniform arrivals during a sustained 3-hour autovacuum, constants matching lib/gitlab/sidekiq_middleware/skip_jobs.rb, recorded in #629387:

delay_by	incremental_database_health_defer_delay	wait p99	executes after recovery, p99	avg deferrals per job
1 min	off (current default)	179 min	1.0 min	90.9
5 min	off	180 min	4.9 min	18.6
1 min	on	202 min	28.8 min	7.5
5 min	on	204 min	28.7 min	5.4

Reading the top two rows: moving to 5 minutes cuts re-enqueue volume roughly 5x (90.9 down to 18.6 deferrals per job) and costs about 4 minutes of additional tail after the database recovers. The p99 wait is essentially unchanged, 179 vs 180 minutes, because the wait is dominated by the length of the autovacuum, not by the polling interval. This MR does not enable incremental_database_health_defer_delay (bottom two rows): that flag adds roughly 23 minutes to the p99 wait and lets work land up to 29 minutes after the database has recovered.

Precedent for 5.minutes among gitlab_sec multi-table watchers

The four Vulnerabilities::* workers that watch the same vulnerability tables this change affects already use 5.minutes:

• Vulnerabilities::AutoDismissWorker (watches vulnerabilities, vulnerability_reads)
• Vulnerabilities::AutoSeverityOverrideWorker
• Vulnerabilities::UpdateAscpAssociationsWorker
• Vulnerabilities::UpdateAscpAssociationsBatchWorker

The convention is not uniform tree-wide: across all schemas there are 27 multi-table watchers still on 1.minute and 20 on 10.minutes. The relevant precedent is the sec vulnerability-table group, not the tree as a whole.

Security::Scans::IngestReportsWorker still uses 1.minute and is deliberately left alone: it watches a single table (vulnerability_occurrences), so the OR-widening argument does not apply to it.

A Changelog: performance trailer with EE: true is included because the governing feature flags are now enabled in production (autovacuum_indicator_uses_context_connection since 2026-09-12, defer_sbom_ingest_reports_on_database_health and defer_store_security_reports_on_database_health both on in gprd), so this is a live behaviour change rather than one hidden behind a default-off flag.

References

• #629387
• !255632 (merged)
• !255634 (merged)
• Parent epic: &23596

Screenshots or screen recordings

No UI change.

How to set up and validate locally

The value is exposed as database_health_check_attrs[:delay_by].

bundle exec rspec ee/spec/workers/sbom/ingest_reports_worker_spec.rb ee/spec/workers/security/store_security_reports_by_project_worker_spec.rb

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.