## Summary Roll out the status filter change in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/260617 (https://gitlab.com/gitlab-org/gitlab/-/work_items/629282), currently behind the `work_item_status_single_column_filter` feature flag. - DRI: @vjain-gl - Team Slack channel: `#g_plan_planning_views` > [!note] > Process and guidance live in the docs — this issue is just the commands and a place to track the rollout. > "Rolling out" means incrementally enabling the flag on GitLab.com to validate stability — it is not the same as releasing the feature, which happens when the flag is removed. > [Feature flag controls](https://docs.gitlab.com/development/feature_flags/controls/) · [Feature flag lifecycle](https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle) With the flag on for a root namespace, filtering by a custom status drops the two branches that cannot use an index (rows on the legacy `system_defined_status_id` column, and items with no status row). The code also checks that the backfill migrations `BackfillConvertedWorkItemStatusIds` and `BackfillMissingWorkItemCurrentStatuses` have finished, so the flag cannot take effect before the rows exist. The "no row" branch is only dropped for issues and tasks; epics keep it until their own backfill lands. ## What could go wrong? - An item that has no status row, or a row still on the legacy column, disappears from a status filter and from its board column. Rows are guaranteed by the two finished backfills and by the conversion worker. Until https://gitlab.com/gitlab-org/gitlab/-/work_items/633143 is deployed, an item created or moved while the group's status license has lapsed gets no row, so the flag stays limited to groups that keep their license (gitlab-org, gitlab-com) until then. - Rollback is disabling the flag: the query goes back to today's three-branch shape, no data is touched. - Watch: Kibana for slow `with_status` / status count queries by `root_namespace_id` in the enabled groups, and the planning views error budget dashboard. ## Events - [Exceptions with work_item_status_single_column_filter:1](https://log.gprd.gitlab.net/app/discover#/?_g=(time:(from:now-1d,to:now))&_a=(index:'7092c4e2-4eb5-46f2-8305-a7da2edad090',query:(language:kuery,query:'json.exception.feature_flag_states.keyword:%22work_item_status_single_column_filter:1%22'),columns:!(json.exception.class,json.exception.message,json.extra.workflow_id,json.meta.caller_id),sort:!(!(json.time,desc)))) - [Events with work_item_status_single_column_filter:1](https://log.gprd.gitlab.net/app/discover#/?_g=(time:(from:now-1d,to:now))&_a=(index:'7092c4e2-4eb5-46f2-8305-a7da2edad090',query:(language:kuery,query:'json.feature_flag_states:%22work_item_status_single_column_filter:1%22'),columns:!(json.meta.caller_id,json.feature_flag_states),sort:!(!(json.time,desc)))) ## Rollout Run all production `/chatops` in [`#production`](https://gitlab.slack.com/archives/C101F3796) and cross-post the results to `#g_plan_planning_views`. - [ ] !260617 merged and deployed to production. - [ ] Both migrations report `finished` on production: ``` /chatops run batched_background_migrations status BackfillConvertedWorkItemStatusIds /chatops run batched_background_migrations status BackfillMissingWorkItemCurrentStatuses ``` - [ ] **Non-production** ``` /chatops gitlab run feature set work_item_status_single_column_filter true --dev --pre --staging --staging-ref ``` - [ ] **Production**, gitlab-org and gitlab-com first: ``` /chatops gitlab run feature set --group=gitlab-org,gitlab-com work_item_status_single_column_filter true ``` - [ ] Verify: open a gitlab-org status board, compare column contents with the flag off and on for one group, check the Start and New columns load in seconds. - [ ] https://gitlab.com/gitlab-org/gitlab/-/work_items/633143 merged and deployed, with its flag on. - [ ] **Production**, all groups: ``` /chatops gitlab run feature set work_item_status_single_column_filter true ``` ## Before global rollout - Docs: not applicable, no user-facing change. - Breaking changes: none. - Change management issue: not required. - External API consumers: not applicable. ## Cleanup Remove the flag in https://gitlab.com/gitlab-org/gitlab/-/work_items/629284 (19.7) once the migrations are finalized (https://gitlab.com/gitlab-org/gitlab/-/work_items/629283). Self-managed switches over on its own when its migrations finish, so the flag only gates GitLab.com. ``` /chatops gitlab run release check <merge-request-url> <milestone> /chatops gitlab run feature delete work_item_status_single_column_filter --dev --pre --staging --staging-ref --production ``` ## Rollback ``` /chatops gitlab run feature set work_item_status_single_column_filter false /chatops gitlab run feature set work_item_status_single_column_filter false --dev --pre --staging --staging-ref ```