> **TL;DR** > > - Iteration 7 wants a row in `work_item_current_statuses` for every work item of every type. > - The read-time "no row" fallback comes back every time a type gains status later (for example requirements or test cases), until that type's history is backfilled. BBMs only count as finalized after a required stop (months). > - The question: a per-namespace covered-types record combined with writing rows everywhere (Option A, current leaning), or a global invariant with the fallback deleted (Option B). ## Context - Epic: https://gitlab.com/groups/gitlab-org/-/work_items/24009. Goal: every work item of every type has a row in `work_item_current_statuses`. - `with_status` (`ee/app/models/concerns/work_items/has_status.rb`) has a read-time "no row" branch for items without a row. - https://gitlab.com/gitlab-org/gitlab/-/work_items/629282 removes that branch behind a flag. It keeps the branch for epics until https://gitlab.com/gitlab-org/gitlab/-/work_items/632560 finishes. It switches self-managed over once the backfill migrations finish. - Question: once every write path keeps the invariant, can the "no row" branch go away completely, and what guarantees it stays true? ## Problem: where rows go missing 1. **Flag-gated types** (epic, ticket) roll out at different times. History only gets rows after each flag is enabled globally. 2. **Free to paid:** items created without the `work_item_status` license have no row. https://gitlab.com/gitlab-org/gitlab/-/work_items/633143 removes the license guard on writes. 3. **CE to EE:** a CE instance has no rows at all. Status is EE-only today, so CE has no application logic to write or update rows (create, close, reopen). 4. **New types gaining status later** (for example requirements, test cases): same as 1, and it repeats for every type. ### Gap: CE to EE - `Gitlab::BackgroundMigration::BackfillMissingWorkItemCurrentStatuses` has an empty `perform` in CE. The implementation is EE-only via `prepend_mod`. - The queue migration has no edition check, so a CE instance runs it as a no-op and marks it finished. After an upgrade to EE it never runs again. - Partly covered today: groups can only convert to custom statuses after the upgrade, and the converted-group worker (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/261044) inserts missing rows when a group converts. - Not covered: namespaces on system-defined statuses keep relying on the fallback. That matters as soon as the fallback is removed for them too, which Option B wants. - Needs confirmation. ## Options ### Option A: Covered-types record per root namespace, plus rows everywhere (current leaning) - Every write path writes a row (https://gitlab.com/gitlab-org/gitlab/-/work_items/633143). - One record per root namespace (`namespace_id`, `covered_base_types`, timestamps). - A namespace-scoped backfill worker fills missing rows and adds the type to `covered_base_types`. Triggered by events instead of BBM finalization: a type gets enabled for the namespace, the namespace converts to custom statuses (the converted-group worker in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/261044 already works this way), or the instance moves from CE to EE. - `with_status` skips the "no row" branch when every filtered type is covered for the namespace. Otherwise the fallback runs as a cold path. - Safety net: a cron job inserts rows for recently created items still missing one, and a metric counts items without a row. - Idea: when an unmarked namespace hits the fallback, enqueue its backfill worker (deduplicated). Self-heals CE to EE, missed write paths and new types. - Pros: no waiting for required stops; works per namespace on GitLab.com and on self-managed; new types and CE to EE use the same mechanism. - Cons: extra state and two query shapes; transfers and imports into a covered namespace must keep the invariant; the fallback code stays. ### Option B: Global invariant, then delete the fallback - Every write path writes a row, one-time BBM per type, then the fallback code is deleted. - Pros: one query shape, less code. - Cons: every type that gains status later needs the fallback back until its BBM finalizes after a required stop. CE to EE needs either status logic in CE or the fallback again. ## Considered, not proposed - Write rows in CE: CE would need status logic for create, close and reopen, which means moving status out of EE (not decided) and more EE override architecture. Related to https://gitlab.com/gitlab-org/gitlab/-/work_items/594820. - Re-run the BBM on CE to EE upgrade: a special case to keep forever; the namespace-scoped worker in Option A covers it. - `status_id` on `issues` with `NOT NULL`: DB-enforced, no join. But `issues` is a large, restricted table. Worth a line on https://gitlab.com/gitlab-org/gitlab/-/work_items/604248. - DB trigger on `issues` INSERT creating the row: catches imports. The default status depends on lifecycle, masking and feature flags the DB can't see. - Write the row on read: filters can't see rows that don't exist yet. ## Decision To be decided. Current leaning: Option A. ## Related - Parent epic: https://gitlab.com/groups/gitlab-org/-/work_items/24009 - Related: https://gitlab.com/gitlab-org/gitlab/-/work_items/633143 (remove license guard on writes) - Related: https://gitlab.com/gitlab-org/gitlab/-/work_items/629282 (remove "no row" branch behind a flag) - Related: https://gitlab.com/gitlab-org/gitlab/-/work_items/632560 (epic backfill) - Related: https://gitlab.com/gitlab-org/gitlab/-/work_items/633146 (ticket backfill) - Related: https://gitlab.com/gitlab-org/gitlab/-/work_items/594820 (Free tier work) - Related: https://gitlab.com/gitlab-org/gitlab/-/work_items/604248 (`status_id` on `issues`) - Related: https://gitlab.com/gitlab-org/gitlab/-/work_items/577431