## Summary Roll out the feature introduced in the [introducing merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255196), currently behind the `defer_store_security_reports_on_database_health` feature flag. - DRI: @bala.kumar - Team Slack channel: `#g_security-foundations` - Group: `group::security foundations` - Milestone: 19.5 - Type: `gitlab_com_derisk`, `default_enabled: false` - Flag definition: `ee/config/feature_flags/gitlab_com_derisk/defer_store_security_reports_on_database_health.yml` - Not an ops flag, not an experiment; there is no A/B measurement associated with this rollout. > [!note] > Process and guidance live in the docs — this issue is just the commands and a place to track the rollout. > "Rolling out" means incrementally enabling the flag on GitLab.com to validate stability — it is not the same as releasing the feature, which happens when the flag is removed. > [Feature flag controls](https://docs.gitlab.com/development/feature_flags/controls/) · [Feature flag lifecycle](https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle) ## What the flag controls `Security::StoreSecurityReportsByProjectWorker` stores security scan results into the `sec` database by way of `Security::Ingestion::IngestReportsService`. It previously had no database-health gating. The introducing merge request adds `defer_on_database_health_signal :gitlab_sec, [::Vulnerabilities::Finding.table_name], 1.minute`, and this flag controls whether that gating is active. When the flag is enabled and a database health indicator returns a stop signal, `Gitlab::SidekiqMiddleware::SkipJobs` reschedules the job instead of running it. The first deferral waits 1 minute; consecutive deferrals back off exponentially up to a 30 minute cap, and that escalation is itself controlled by the separate, pre-existing `incremental_database_health_defer_delay` feature flag. The flag takes no feature actor — it is a fleet-wide throttle evaluated at job-fetch time with no project or user in scope. The rollout is therefore boolean on/off; percentage-of-actors and per-project, per-group, or per-user targeting do not apply. Of the four database health indicators, `WalRate` is the one expected to trip in practice. Its configured SLO for the sec database is 70 MB/s of WAL generation. ## Evidence **Sec DB writes per job by worker class (gprd)**  Production log analysis identified this worker as the second-heaviest per-job writer to the sec database. Over a 12-hour window ending 2026-09-12 08:30 UTC, the Kibana panel "Sec DB writes per job by worker class (gprd)" shows `Security::StoreSecurityReportsByProjectWorker` peaking at 2,807 sec-database writes in a single job, second only to `Sbom::IngestReportsWorker` at 16,896, with every other worker two orders of magnitude lower (`Security::StoreScansWorker` 346, `Sbom::RemoveOldDependencyGraphsWorker` 152, `Sbom::BuildDependencyGraphWorker` 86). Note that the panel is titled "p99" but its legend series are prefixed `(100)`, so these are peak per-job writes rather than a 99th percentile. ## What could go wrong? - Deferral delays security scan result ingestion, so vulnerability data lags behind the pipeline that produced it for as long as the sec database stays unhealthy. - Exponential backoff means an individual job can be pushed out up to 30 minutes. - A backlog of deferred jobs can accumulate while the sec database is unhealthy and release together once health recovers — watch for a release burst. - The `AutovacuumActiveOnTable` health indicator does not currently observe the sec database (https://gitlab.com/gitlab-org/gitlab/-/work_items/628693), so effective gating today comes from the cluster-wide indicators only. ## What to monitor - Prometheus counter `sidekiq_jobs_skipped_total{action="deferred", reason="database_health_check"}` filtered to `Security::StoreSecurityReportsByProjectWorker`. - Kibana Sidekiq logs where `json.class` is `Security::StoreSecurityReportsByProjectWorker` and `json.job_deferred_by` is `database_health_check`; `json.deferred_count` shows backlog depth. - Sec database WAL generation against the [primary DB node WAL generation saturation runbook](https://runbooks.gitlab.com/patroni/primary_db_node_wal_generation_saturation/). - Security scan ingestion latency. ## Events - [Exceptions with defer_store_security_reports_on_database_health:1](https://log.gprd.gitlab.net/app/discover#/?_g=(time:(from:now-1d,to:now))&_a=(index:'7092c4e2-4eb5-46f2-8305-a7da2edad090',query:(language:kuery,query:'json.exception.feature_flag_states.keyword:%22defer_store_security_reports_on_database_health:1%22'),columns:!(json.exception.class,json.exception.message,json.extra.workflow_id,json.meta.caller_id),sort:!(!(json.time,desc)))) - [Events with defer_store_security_reports_on_database_health:1](https://log.gprd.gitlab.net/app/discover#/?_g=(time:(from:now-1d,to:now))&_a=(index:'7092c4e2-4eb5-46f2-8305-a7da2edad090',query:(language:kuery,query:'json.feature_flag_states:%22defer_store_security_reports_on_database_health:1%22'),columns:!(json.meta.caller_id,json.feature_flag_states),sort:!(!(json.time,desc)))) - [Error rate and other graphs by modifying the examples in the Visualization Library](https://log.gprd.gitlab.net/app/visualize#/?_g=h@358d019&s=FF%20Observability) Feature Flag events are only logged by default for feature flags marked for the current or future milestones. To enable while the feature flag is active, see https://docs.gitlab.com/development/feature_flags/#logging ## Rollout Run all production `/chatops` in [`#production`](https://gitlab.slack.com/archives/C101F3796) and cross-post the results to `#g_security-foundations`. Background: [incremental rollout process](https://docs.gitlab.com/development/feature_flags/controls/#process), [feature actors](https://docs.gitlab.com/development/feature_flags/#feature-actors). This flag takes no feature actor, so percentage rollout and actor targeting (`--actors`, `--project=`, `--group=`, `--user=`) do not apply; the rollout is a single boolean toggle. **Non-production** ``` /chatops gitlab run feature set defer_store_security_reports_on_database_health true --dev --pre --staging --staging-ref ``` **Production** — single-step enable (watch dashboards after enabling): ``` /chatops gitlab run feature set defer_store_security_reports_on_database_health true ``` ## Before global rollout This flag has no percentage stage, so this is a final check before enabling in production rather than a check before the last step of a staged rollout. Confirm the relevant gotchas before enabling — see [enabling a feature for GitLab.com](https://docs.gitlab.com/development/feature_flags/controls/#enabling-a-feature-for-gitlabcom): - [Docs + version history](https://docs.gitlab.com/development/documentation/feature_flags/) updated - [Breaking changes](https://docs.gitlab.com/development/documentation/release_notes/#deprecations-removals-and-breaking-changes) announced, if any - [Change management issue](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/change-management/#feature-flags-and-the-change-management-process) opened, if required - [External API consumers](https://docs.gitlab.com/development/feature_flags/#do-not-use-feature-flags-in-external-api-consumers) handled with a fail-open mechanism, if applicable — not applicable here, since this flag only gates internal Sidekiq job scheduling and has no external API surface. ## Cleanup Remove the flag once [deemed stable](https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle) — see [cleaning up](https://docs.gitlab.com/development/feature_flags/controls/#cleaning-up). Track it here, or open a follow-up [Feature Flag Cleanup issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/new?description_template=Feature%20Flag%20Cleanup). Remove the flag and its YAML definition from the codebase, then: ``` /chatops gitlab run release check https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255196 19.5 /chatops gitlab run feature delete defer_store_security_reports_on_database_health --dev --pre --staging --staging-ref --production ``` ## Rollback Disable the flag. The gating disappears immediately and the worker runs unconditionally again, with no data migration, no cleanup, and no state left behind. ``` /chatops gitlab run feature set defer_store_security_reports_on_database_health false # production /chatops gitlab run feature set defer_store_security_reports_on_database_health false --dev --pre --staging --staging-ref # non-production /chatops gitlab run feature delete defer_store_security_reports_on_database_health --dev --pre --staging --staging-ref --production # remove entirely ```