Default enable discard_stale_mergeability_verdicts
Defaults discard_stale_mergeability_verdicts to on and switches its type from gitlab_com_derisk to beta, since gitlab_com_derisk flags cannot be default-enabled. The underlying fix has been at 100% on GitLab.com since 2026-08-26 and this just changes the default for everyone else. No code or spec changes.
Detailed context for AI agents
What the flag does
In MergeRequests::MergeabilityCheckService, the flag makes the service claim the merge status write in the database instead of writing it unconditionally. This means a mergeability verdict is discarded if the merge request no longer has the target branch or the source diff the verdict was computed against, instead of overwriting a fresher verdict with a stale one.
Why beta instead of gitlab_com_derisk
lib/feature/shared.rb sets can_be_default_enabled: false for the gitlab_com_derisk flag type, so it cannot be flipped to default-enabled while staying in that type. beta allows default_enabled: true and is also the right fit here because we want self-managed operators to retain the ability to switch the behavior off.
Rollout history on GitLab.com
- Enabled for a personal project, then for gitlab-org/gitlab, on 2026-08-21 (fix verified with the flag on, bug reproduced with it off)
- 10% / 25% / 50% of actors on 2026-08-26
- 100% on 2026-08-26
- Disabled on 2026-09-01 while investigating a Sidekiq concurrency-limit spike, suspected to be caused by workers held open too long. This turned out to be unrelated.
- Re-enabled to 100% on 2026-09-02
- Has remained at 100% since, with no issues
Risk and what to watch
If the default-on behavior is wrong, a merge status write can be refused in error, leaving a merge request stuck at checking ("Checking mergeability" in the UI) because nothing re-enqueues a check. The signal to watch post-deploy is a rise in merge requests stuck in checking.
Rollback
No data repair needed. Just disable the flag: Feature.disable(:discard_stale_mergeability_verdicts). Self-managed operators can do the same locally if they want to opt out.
Why no code or spec changes
The original fix merged in !247555 (merged) (milestone 19.3). Specs in spec/services/merge_requests/mergeability_check_service_spec.rb already cover both flag states: the enabled state is the unstubbed default, and separate self-contained contexts stub the flag off. This MR only changes the default and the flag type, so no code or spec changes are needed.
Why no docs edit is needed
doc/administration/feature_flags/list.md uses layout: feature_flags and is generated from the flag YAML definitions, so the flag will appear there automatically once its type is beta.
Scope
This does not remove the flag. Removal is a separate, later step.
References:
- Bug: #606487 (closed)
- Rollout issue: #607205 (closed)
- Original fix: !247555 (merged)