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:

Merge request reports

Loading
Loading