### Summary After a CI partition rotation leaves a `ci_partitions` row with `pipelines_id_range = 'empty'`, every worker that resolves a pipeline by id raises `NoMethodError: undefined method 'begin' for nil` in `Gitlab::Ci::Pipeline::PartitionCache.store`. Pipelines are created but never leave the `created` state, and CI is dead instance-wide until the row is changed or the code is patched. `Gitlab::Ci::Pipeline::PartitionCache#load_from_database` guards with `where.not(pipelines_id_range: nil)`, but that is a SQL NULL check. A PostgreSQL `empty` range is not NULL, so the row passes the guard — and Rails casts it to Ruby `nil`, which `store` then calls `.begin` on. ### Steps to reproduce 1. Run an instance long enough for a partition rotation to drain a partition (`ci_partitions.pipelines_id_range = 'empty'`, done by `Ci::Partitions::SyncService`), or set it directly: `UPDATE ci_partitions SET pipelines_id_range = 'empty' WHERE id = <drained id>;` 2. Invalidate the cache so the next read goes to the database: `Gitlab::Ci::Pipeline::PartitionCache.invalidate` (the sync service does this itself on rotation). 3. Push a commit to a project with a `.gitlab-ci.yml`. ### What happens The pipeline and its jobs are created, but no job is ever queued. The job is visible under the pipeline and absent from the project's Jobs list. `PipelineProcessWorker`, `Ci::InitialPipelineProcessWorker`, `PipelineHooksWorker` and `Ci::TrackPipelineTriggerEventsWorker` all fail in \~40 ms, retry 25 times, and land in Sidekiq's DeadSet. ``` "exception.class":"NoMethodError" "exception.message":"undefined method `begin' for nil" "exception.backtrace":[ "lib/gitlab/ci/pipeline/partition_cache.rb:53:in `block in store'", "lib/gitlab/ci/pipeline/partition_cache.rb:53:in `map'", "lib/gitlab/ci/pipeline/partition_cache.rb:53:in `store'", "lib/gitlab/ci/pipeline/partition_cache.rb:40:in `load_ranges'", "lib/gitlab/ci/pipeline/partition_cache.rb:22:in `ranges'", "lib/gitlab/ci/pipeline/partition_cache.rb:18:in `partition_ids_for'", "lib/gitlab/ci/pipeline/by_id_lookup.rb:29:in `find_in_partitions'", "lib/gitlab/ci/pipeline/by_id_lookup.rb:20:in `execute'", "app/models/ci/pipeline.rb:609:in `find_by_id'" ] ``` `ci_partitions` on the affected instance — row 103 is the trigger, drained the day before the outage began; row 105's genuine NULL is filtered correctly by the existing guard: ``` id | status | current_from | current_until | pipelines_id_range -----+--------+-------------------------------+------------------------------+-------------------- 105 | 0 | | | 104 | 2 | 2026-08-18 02:00:09.684038+00 | | [5,) 103 | 3 | 2026-07-19 02:00:04.379606+00 | 2026-08-18 02:00:09.684038+00 | empty 102 | 3 | 2024-10-05 02:00:04.832032+00 | | 101 | 3 | 2024-10-05 02:00:04.832032+00 | 2024-10-05 02:00:04.832032+00 | ``` ### Root cause `lib/gitlab/ci/pipeline/partition_cache.rb` (identical in 19.2.4 and in master as of 2026-08-19): ```ruby def load_from_database ::Ci::Partition .where.not(pipelines_id_range: nil) # SQL NULL check only .pluck(:id, :pipelines_id_range) .to_h end def store(hash) tuples = hash.map { |partition_id, range| [partition_id, range.begin, range.end, range.exclude_end?] } ... end ``` `ActiveRecord::ConnectionAdapters::PostgreSQL::OID::Range#cast_value` begins with `return if ["empty", ""].include? value`, so a drained partition arrives in Ruby as `nil` despite being non-NULL in SQL. `store` assumes every value is a `Range`. Because `load_ranges` only reaches `store` on a Redis cache miss, the failure starts when the cache is next cold — which is exactly when `Ci::Partitions::SyncService` invalidates it during the rotation that created the `empty` row. From then on every attempt to repopulate the cache raises, so the outage is permanent rather than transient. ### Proposed fix ```ruby .pluck(:id, :pipelines_id_range) .to_h .compact ``` `Hash#compact` drops the nil values the SQL guard cannot see. Alternatively filter in SQL with `where("pipelines_id_range <> 'empty'::int8range")`, or make `store`/`covers_any?` nil-tolerant. ### Impact Any self-managed instance is affected after its first partition rotation that drains a partition. There is no error surfaced in the UI — the pipeline sits in `created` with no explanation, which makes it look like a runner or configuration problem. ### Workaround for administrators Patch `load_from_database` as above in `/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/ci/pipeline/partition_cache.rb`, delete the Redis key `ci:pipeline:partition_cache:v1`, and restart puma and sidekiq. Jobs already in the DeadSet do not retry; re-run those pipelines. The patch must be reapplied after every upgrade. ### Versions - GitLab 19.2.4, self-managed, omnibus, Linux, PostgreSQL (omnibus bundled) - Code path unchanged in `master` at the time of writing