## Context Parent epic &20933 replaced the single `Geo::UploadReplicator` with 23 per-partition upload replicators. All 23 are merged. Their `geo_<name>_replication` feature flags are `default_enabled: false`. The legacy flag `geo_upload_replication` is `default_enabled: true`. While `geo_upload_replication` is on, the partition replicators do not replicate. `Upload#partition_model_replication_enabled?` returns false, and `Geo::PartitionUploadRegistry` disables the registry consistency worker. Partition flags currently only enable primary checksumming. Replication of partitions starts the moment the legacy flag is turned off. Partition verification adopts the parent checksum from `upload_states` via `Geo::Concerns::UploadReplicatorBehavior#calculate_checksum`. `upload_states` must stay until cleanup, which is tracked in Phase 6b (&23545). ## Plan: two release-bound events - **Event A, milestone 19.5 (required stop):** set all 23 `geo_<name>_upload_replication` flags and their `geo_<name>_upload_force_primary_checksumming` flags to `default_enabled: true` in one batch. The primary backfills 23 state tables and adopts checksums. This is DB writes only, no file reads. Checksum adoption is bounded by the shared `verification_max_capacity` pool, default 10. The state backfill runs one worker per partition, outside that pool. Secondaries are unaffected while the legacy flag is on. - **Event B, milestone 19.6:** set `geo_upload_replication` to `default_enabled: false`. The registry consistency worker backfills 23 registry tables on the secondary. Existing files are not re-downloaded, per `ok_to_skip_download?`, but each gets a sync job and a verification pass. The Geo Sites UI changes from one Uploads row to 23 rows starting at 0%, so #628122 must ship first. Event B has two more prerequisites, both in 19.6. The `uploads_*` status fields and `geo_uploads_*` gauges must keep reporting as aggregates of the partitions (#628546), and the legacy Uploads admin URLs must render overview pages for the partitions (#628547). Without them Event B leaves the legacy metrics frozen, the replication details page empty, and the Data management page returning 404. With them, everything administrators and API consumers see as Uploads is unchanged. The one exception is the GraphQL `uploadRegistries` field, which is deprecated in Phase 6b. Because 19.5 is a required stop, every secondary already has the partition replicators enabled and consumes partition events from a 19.6 primary. Only redundant legacy backfill happens until the secondary upgrades. Before either default changes, the force-checksumming flags are enabled on staging and staging-ref, and the full switch is run on staging-ref. Staging-ref is the only GitLab-run environment with a Geo secondary. GitLab.com production has no Geo and staging has a primary only, so staging-ref is the only pre-release observation of partition replication and the Event B backfill. #589924 is the rollout log and holds the order of flips. **Risk.** For self-managed and Dedicated instances the release is the switch. There is no ramp and no opt-in. Self-managed administrators can re-enable `geo_upload_replication` on the Rails console. Dedicated tenants cannot, so for them the 19.6 upgrade is one way unless a GitLab operator intervenes. This is why the staging-ref soak of at least 24 hours is a hard prerequisite for Event B. ## Exit criteria - All 23 partition flags default on in 19.5. - `geo_upload_replication` default off in 19.6. - Staging-ref replicates uploads through the partition replicators only, after a soak of at least 24 hours with `geo_upload_replication` off. - Legacy `uploads_*` status fields and `geo_uploads_*` gauges keep reporting, as aggregates of the partitions. - `/admin/geo/sites/:id/replication/uploads` and `/admin/data_management/uploads` render the partition overview pages. - Upgrade notes published for 19.5 and 19.6.