## Summary Roll out [the feature](https://gitlab.com/gitlab-org/gitlab/-/work_items/632453) currently behind the `resolve_project_access_from_memberships` feature flag. With the flag on, a user's role on a project is worked out from their memberships and group or project shares when it's checked, instead of being read from the precomputed `project_authorizations` table. The goal is correct roles (including custom roles) without waiting for `project_authorizations` to be refreshed. - DRI: @imand3r - Team Slack channel: `#g_sscs_authorization` - Introduced by: !263758 - Actor: the user (percentage of actors). Each user is either fully on or fully off. > [!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? - **Wrong access.** If the new path gives a different role than `project_authorizations`, users could gain or lose access to projects. We compare 403/404 rates, per endpoint, for users with the flag on and off. So far the extra denials come from a few heavy clients that were already being denied before the flag. - **Database load.** Each access check runs about 2 more queries (p90 19 vs 17). Watch main database CPU, especially the busiest replica. Lists of issues from many projects add the most queries. `batch_permission_check_preloads`, fully enabled on GitLab.com since 2026-10-26, removes that extra cost on REST issue lists, but not on GraphQL issue lists. - **Slow rollbacks for background jobs.** Web requests pick up a flag change within about a minute. Sidekiq jobs take about 30 minutes, so a rollback takes about 30 minutes to reach background jobs. Request logs record which path each request used in `json.authz_project_access_source` (`memberships` or `project_authorizations`), so flag-on and flag-off users can be compared directly. ## Events - [Exceptions with resolve_project_access_from_memberships: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:%22resolve_project_access_from_memberships:1%22'),columns:!(json.exception.class,json.exception.message,json.extra.workflow_id,json.meta.caller_id),sort:!(!(json.time,desc)))) - [Events with resolve_project_access_from_memberships: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:%22resolve_project_access_from_memberships:1%22'),columns:!(json.meta.caller_id,json.feature_flag_states),sort:!(!(json.time,desc)))) - [Error rate and other graphs by modifying the examples in the Visualization Library](https://log.gprd.gitlab.net/app/visualize#/?_g=h@358d019&s=FF%20Observability) ## Rollout Run all production `/chatops` in [`#production`](https://gitlab.slack.com/archives/C101F3796) and cross-post the results to `#g_sscs_authorization`. Background: [incremental rollout process](https://docs.gitlab.com/development/feature_flags/controls/#process), [feature actors](https://docs.gitlab.com/development/feature_flags/#feature-actors). **Non-production** - [x] Staging: 100% since 2026-10-23 **Production** — percentage rollout (wait ≥15 min between steps, watch dashboards): ``` /chatops gitlab run feature set resolve_project_access_from_memberships <percentage> --actors ``` - [x] Enabled for @imand3r as an actor (2026-10-24 03:39 UTC) - [x] 1% (2026-10-23 23:05 UTC) - [x] 5% (2026-10-24 01:32 UTC) - [x] 10% (2026-10-26 15:52 UTC) - [x] 20% (2026-10-26 17:43 UTC) - [x] 35% (2026-10-26 20:04 UTC) - [x] 50% - [x] 100% ## 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): - [Docs + version history](https://docs.gitlab.com/development/documentation/feature_flags/) updated - [Breaking changes](https://docs.gitlab.com/development/documentation/release_notes/#deprecations-removals-and-breaking-changes) announced, if any - [Change management issue](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/change-management/#feature-flags-and-the-change-management-process) opened, if required - [External API consumers](https://docs.gitlab.com/development/feature_flags/#do-not-use-feature-flags-in-external-api-consumers) handled with a fail-open mechanism, if applicable ## 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). Track it here, or open a follow-up [Feature Flag Cleanup issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/new?description_template=Feature%20Flag%20Cleanup). 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 resolve_project_access_from_memberships --dev --pre --staging --staging-ref --production ``` ## Rollback ``` /chatops gitlab run feature set resolve_project_access_from_memberships false # production /chatops gitlab run feature set resolve_project_access_from_memberships false --dev --pre --staging --staging-ref # non-production /chatops gitlab run feature delete resolve_project_access_from_memberships --dev --pre --staging --staging-ref --production # remove entirely ```