## Summary Roll out [the feature](https://gitlab.com/gitlab-org/gitlab/-/work_items/594236) currently behind the `read_relative_positions_from_work_item_positions` feature flag. The flag switches `Issue` relative-position **reads** to source `relative_position` from the `work_item_positions` table instead of `issues.relative_position` (introduced in gitlab-org/gitlab!240241). Writes are unaffected; the existing sync trigger keeps the two columns consistent. - DRI: @vjain-gl - Team Slack channel: `#g_planning_views` <!-- confirm/adjust --> > [!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) ## What could go wrong? ⚠️ **Do not enable this flag on production until the root-column + root-leading index + root-scoping MR (follow-up 1 of #594236) is deployed.** This MR relocates reads only; the group-wide scope is unchanged, so with the flag on and no index the neighbour/list queries are *slower* than today (DB-lab: ~13.5 s / ~6M buffers vs. ~5.25 s today; the index brings it to ~0.245 ms). Enabling early would regress relative-position ordering/reorder queries on large top-level groups (e.g. `gitlab-org`) and can cause statement timeouts. - Blast radius: issue/work-item list & board ordering, drag-to-reorder, and the move flow for any namespace the flag is enabled on. - Dashboards to watch: Rails request/SQL latency and statement-timeout rates for `Issue` ordering endpoints on <https://dashboards.gitlab.net>. - Stale positioning root after transfers. relative_positioning_namespace_id is denormalized and only refreshed by the issues write trigger, so a group/project transfer can leave it pointing at the old root. Enabling before transfer handling is in place would make transferred items filter by the wrong root (drop from / appear in the wrong group's ordered lists). Same class of maintenance as traversal_ids. ## Rollout Run all production `/chatops` in [`#production`](https://gitlab.slack.com/archives/C101F3796) and cross-post results to the team channel. Background: [incremental rollout process](https://docs.gitlab.com/development/feature_flags/controls/#process), [feature actors](https://docs.gitlab.com/development/feature_flags/#feature-actors). The flag actor is a **root namespace**, so enable per top-level group. **Non-production** ``` /chatops gitlab run feature set read_relative_positions_from_work_item_positions true --dev --pre --staging --staging-ref ``` **Production** — enable per top-level group first (start with a GitLab-owned group), watch dashboards ≥15 min between steps: ``` /chatops gitlab run feature set --group=gitlab-org read_relative_positions_from_work_item_positions true ``` Then widen gradually before any global enable: ``` /chatops gitlab run feature set read_relative_positions_from_work_item_positions <percentage> --actors ``` ## Before global rollout Confirm the relevant gotchas before going to 100% — see [enabling a feature for GitLab.com](https://docs.gitlab.com/development/feature_flags/controls/#enabling-a-feature-for-gitlabcom): - [ ] Transfer handling for relative_positioning_namespace_id merged + deployed (keeps the root fresh on group/project moves) - Follow-up index/root-scope MR merged **and deployed to gprd** - Read cutover validated on a real large group (fast plan confirmed) - [Change management issue](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/change-management/#feature-flags-and-the-change-management-process) opened, if required ## Cleanup Remove the flag once [deemed stable](https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle) — see [cleaning up](https://docs.gitlab.com/development/feature_flags/controls/#cleaning-up). Remove the flag and its YAML definition from the codebase, then: ``` /chatops gitlab run release check <merge-request-url> <milestone> /chatops gitlab run feature delete read_relative_positions_from_work_item_positions --dev --pre --staging --staging-ref --production ``` ## Rollback ``` /chatops gitlab run feature set read_relative_positions_from_work_item_positions false # production /chatops gitlab run feature set read_relative_positions_from_work_item_positions false --dev --pre --staging --staging-ref # non-production ```