Dynamic Partitions not being created automatically

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Title: partition_manager_sync_partitions feature flag disabled by default on self-managed EE causes silent partition creation failure and data loss risk

Type: Bug

Severity: High

GitLab version: Confirmed on 19.1.1-ee, suspected present since at least 18.x

Summary

On self-managed GitLab EE instances, the partition_manager_sync_partitions ops feature flag is disabled by default. This causes Gitlab::Database::Partitioning.sync_partitions to silently return without creating any partitions. The Sidekiq cron job Database::PartitionManagementWorker and the rake task gitlab:db:create_dynamic_partitions both call this method and therefore also silently do nothing. No error is logged anywhere.

The result is that dynamic partitions are never created ahead of time, causing application failures when a new month's partition is missing.

Steps to reproduce

  1. Install GitLab EE self-managed (any recent version)
  2. Check the feature flag state:

gitlab-rails runner "puts Feature.enabled?(:partition_manager_sync_partitions, type: :ops)"

  1. Observe it returns false
  2. Run the partition manager:

gitlab-rake gitlab:db:create_dynamic_partitions

  1. Observe it completes silently with no output and creates no partitions
  2. Check Sidekiq logs for Database::PartitionManagementWorker — job shows db_write_count: 0 with no errors

Expected behaviour

Dynamic partitions should be created automatically up to 6 months in advance. The partition manager should either work by default on self-managed instances, or log a clear warning when the feature flag prevents it from running.

Actual behaviour

The partition manager silently exits without creating partitions due to:

return unless Feature.enabled?(:partition_manager_sync_partitions, type: :ops)

No warning, no error, no log entry. The Sidekiq worker reports job_status: done with db_write_count: 0.

Impact

On our instance, dynamic partitions existed continuously from September 2022 (initial installation) through to _202606(June 2026), at which point the sequence stops. With a 6-month lookahead, June 2026 partitions should have been created around December 2025. This strongly suggests the partition_manager_sync_partitions flag was either disabled or introduced without being enabled on self-managed instances at some point around December 2025, and has been silently failing ever since.

The consequences on our instance were:

  1. Dynamic partitions for July 2026 (_202607) were never created ahead of time
  2. CI pipeline failures at midnight on July 1st when jobs attempted to write to missing partition tables
  3. Login failures as audit event writes failed against missing audit_events_202607 partition
  4. Manual partition creation and a subsequent GitLab upgrade (19.0.1 → 19.1.1) were required to restore service
  5. Significant unplanned downtime and manual intervention required

Workaround

Enable the feature flag manually:

gitlab-rails runner "Feature.enable(:partition_manager_sync_partitions)"

Then run the partition manager to catch up:

gitlab-rake gitlab:db:create_dynamic_partitions

Questions for GitLab team

  1. Is partition_manager_sync_partitions intentionally disabled by default on self-managed EE? If so, why, and where is this documented?
  2. Was this flag enabled by default prior to approximately December 2025, and if so, when and why was it disabled?
  3. Should the worker and rake task log a warning when this flag prevents execution, rather than silently succeeding?
  4. Should upgrade scripts check and enable this flag if it is required for correct operation?
  5. Are other self-managed EE instances affected by this, and if so, is a stability advisory warranted?

Environment

  • GitLab EE 19.1.1 (also affected on 18.x)
  • Self-managed, single-node omnibus installation
  • Ubuntu 22.04
  • PostgreSQL 16 (bundled)
Edited by 🤖 GitLab Bot 🤖