## Summary `gitlab_subscription_histories.hosted_plan_name_uid` has **2,665** rows out of sync with the authoritative `plans.plan_name_uid` — the histories side of the same drift that !234704 corrected for `gitlab_subscriptions` (2,193 rows), but histories never got the fix. This **blocks** the histories read swap (#596995 / !242975). **Audit complete (2026-07-22):** `gitlab_subscription_histories` is the only table with drift. Every other denormalized plan-uid column is measured-clean or out of scope (see table). **Currently dormant:** no code reads `hosted_plan_name_uid` on histories yet — master reads still go through `hosted_plan_id`. The 2,665 wrong values are inert and only produce wrong results once !242975 flips those reads. So this fix is a **prerequisite that must land + finalize before !242975 merges**, not a live production bug. The affected reads (once flipped): `with_all_ultimate_plans` (expired-license cron) and `premium_plan_not_renewed?`. ## Root cause (per @fjedelhauser's investigation in #596996) The drift was **not** caused by !230811. That MR only *exposed* it: switching subscription reads to `hosted_plan_name_uid` loaded the wrong plans → incident `gitlab-com/request-for-help#4686` → revert !234256 (severity::2, type::bug). The actual cause is a deploy gap in the `set_hosted_plan_name_uid` callback on `GitlabSubscription`: 1. The callback first shipped via !215322 for a **~4.5h window on 2025-12-19** (~10:09–14:53 UTC), then was reverted the same day. 2. **~5-week gap (2025-12-19 → 2026-01-23)** with no callback: new subscriptions got `hosted_plan_name_uid = NULL`, and subscriptions whose `hosted_plan_id` changed (e.g. premium → ultimate) never had the uid updated → mismatch. 3. Callback re-added **2026-01-23**, but its guard clause prevents self-healing: ```ruby return if hosted_plan_name_uid.present? && !hosted_plan_id_changed? ``` A row with a stale-but-present uid whose `hosted_plan_id` changed during the gap is stuck permanently wrong. Evidence: every mismatched subscription row has `created_at ≤ 2025-12-22` and `updated_at ≥ 2025-12-22`. Because it is a bounded historical event (not recurring), a one-time re-sync migration fixes it — which is exactly what !234704 did for `gitlab_subscriptions`. ## Why histories is affected (and the siblings weren't) History rows copy the subscription's uid at write time (`create_from_change` / `TRACKED_ATTRIBUTES`) and are immutable, so rows snapshotted during the gap inherited the stale values. The backfill only touched `IS NULL` rows, so the wrong **non-NULL** ones survived, and !234704 only touched `gitlab_subscriptions`. Measured: **2,665** mismatches (2026-07-22). The sibling columns were each audited independently on a production clone (or, for the CI-database tables, by code + a within-CI check) and came back clean or out of scope. ## Tables & status (audited 2026-07-22) | Table.column | Status | Detail | | --- | --- | --- | | `plans.plan_name_uid` | N/A | Source of truth (the enum) | | `gitlab_subscriptions.hosted_plan_name_uid` | ✅ Fixed | !234704 — 2,193 rows; re-verified **0** mismatches on prod clone | | `gitlab_subscription_histories.hosted_plan_name_uid` | 🔧 Fix in progress | **2,665** confirmed; inherited from subscriptions. Dormant — no reader in master (reads use `hosted_plan_id`); only bites when !242975 flips reads → gate for that MR. Fix in !246818 (in review); drain + finalize tracked in #607406 | | `plan_limits.plan_name_uid` | ✅ Clean | **0** mismatches (prod clone); `plan_id` immutable per row. #596997 | | `ci_pending_builds.plan_name_uid` | ✅ Clean | Within-CI: **0** null-parity mismatches (~16.5K rows). Value drift structurally impossible — `plan_name_uid` + `plan_id` co-written from one plan object + rows ephemeral. CI-owned | | `ci_runners.allowed_plan_name_uids` | ✅ No fix needed | 53/123 instance runners have non-canonical `allowed_plans` names dropped by `filter_map` (8 zero-uid, 45 partial). Confirmed **cosmetic** — none had real `allowed_plan_ids`, so no plan restriction was ever enforced or lost (queue is uid-only, fail-open on empty; no bypass). No value drift (append-only enum; `SystemDefined::Plan` ids == `PLAN_NAME_UID_LIST`). Junk names only; CI-owned cleanup at most | | `subscription_add_on_purchases.subscription_add_on_uid` | ✅ Clean | **0** mismatches across ~1.48M (prod clone); NOT NULL + immutable FK. #15784 | ## Tasks - [x] `gitlab_subscriptions` — fixed by !234704; re-verified 0 (2026-07-22) - [x] `gitlab_subscription_histories` — 2,665 confirmed → `FixGitlabSubscriptionHistoriesHostedPlanNameUid` (queue-only, mirrors !234704) in review in !246818; BBM drain (~15h26m at batch size 10,000) + finalize tracked in #607406 → re-verify `0`. **Blocks #596995 / !242975**; before the Phase 3 column drop (#600316). - [x] `plan_limits` — audited clean, 0 (2026-07-22) (#596997) - [x] `ci_pending_builds` — audited clean, within-CI 0 (2026-07-22) (CI-owned) - [x] `ci_runners.allowed_plan_name_uids` — audited: no fix needed (53 instance runners have cosmetic non-canonical `allowed_plans` names; never restricted → no bypass). CI-owned cleanup at most - [x] `subscription_add_on_purchases` — audited clean, 0 (2026-07-22) (#15784) ## Fix pattern (per table) Mirror !234704: ```sql UPDATE <table> SET <uid_col> = plans.plan_name_uid FROM plans WHERE <table>.<plan_id_col> = plans.id AND <table>.id IN (<sub_batch>) AND <table>.<uid_col> IS DISTINCT FROM plans.plan_name_uid ``` Then a queue migration (`restrict_gitlab_migration gitlab_schema: :gitlab_main_org`) and a later finalize migration (`ensure_batched_background_migration_is_finished(..., finalize: true)`). Bake, re-verify `0`. ## References - Root cause + evidence: #596996 (discussion) · Incident: `gitlab-com/request-for-help#4686` - Exposed by (reverted): !230811 · Revert: !234256 · Callback origin: !215322 - Subscriptions data fix (precedent): !234704 · Backfill finalize: !231589 - Blocks: #596995 (and !242975) · Phase 3 column drop: #600316 - Parent: #571422 / #571424 · Related: #596997, #15784