Remove the auto_merge_readd_to_train_after_completed_pipeline feature flag
Merge requests that were dropped from a merge train and left with that train's finished pipeline as their head pipeline now go back on the train and get a fresh train pipeline, instead of hanging with auto-merge enabled. This removes the auto_merge_readd_to_train_after_completed_pipeline feature flag and makes that behaviour the default. Nothing merges without the new train pipeline passing, and approvals, drafts, discussions, blocking MRs, external status checks and security policies are still enforced.
Resolves #627754 (closed)
Detailed context for AI agents
What does this MR do and why?
Removes the feature flag auto_merge_readd_to_train_after_completed_pipeline (default_enabled: false, type gitlab_com_derisk, milestone 19.4, group::pipeline execution) and makes the behaviour it gated unconditional.
The bug: when a merge request is dropped from a merge train, its head pipeline stays the train's finished pipeline. A finished merge train pipeline cannot be retried. Before the fix, auto-merge required that pipeline to pass before re-adding the MR to the train. The "merge train" strategy was also hidden, because the conflict check reported "checking" after every push to a busy target branch. So the merge request hung with auto-merge enabled until a fresh pipeline happened to run.
What the fix does (now unconditional):
AutoMerge::AddToMergeTrainWhenChecksPassService#processskips the CI check when the head pipeline is a completed merge train pipeline, the MR is not on a train, and no pipeline is being created. The MR goes back on the train and gets a fresh train pipeline.AutoMerge::MergeTrainService#skippable_available_for_checksskips the conflict check in the same situation, so the merge train strategy stays available.- A concurrency guard in
AddToMergeTrainWhenChecksPassService#processwas gated on the same flag and is now unconditional too. It returns early if a concurrent run already put the MR on the train, instead of aborting and destroying that car.
Code changes:
- Removed the
readd_to_train_enabled?helper and its two uses inee/app/services/auto_merge/add_to_merge_train_when_checks_pass_service.rb. - Removed the
Feature.enabled?check inee/app/services/auto_merge/merge_train_service.rb. - Deleted
ee/config/feature_flags/gitlab_com_derisk/auto_merge_readd_to_train_after_completed_pipeline.yml. - Removed four flag-off spec contexts across
ee/spec/services/auto_merge/add_to_merge_train_when_checks_pass_service_spec.rb,ee/spec/services/auto_merge/merge_train_service_spec.rbandee/spec/services/ee/auto_merge_service_spec.rb. The flag-on specs that cover the behaviour are unchanged. - No docs referenced the flag.
- Commit trailers:
Changelog: fixed,EE: true.
Rollout state (from the rollout issue log): enabled on staging on 2026-09-21, and enabled on production scoped to specific projects on 2026-09-21. The rollout issue carries the label "feature flag state::enabled".
Verification: the three spec files above were run locally (102 examples, 0 failures) and RuboCop is clean on the changed files.
References
- Resolves rollout issue: #627754 (closed)
- Flag introduced by: !253707 (merged)
- Original bug: #627635 (closed)
Screenshots or screen recordings
Not applicable. This change is backend-only, with no UI change.
How to set up and validate locally
- On an EE instance, in a project with merge trains enabled and "Pipelines must succeed" on, open a merge request with a passing pipeline and set auto-merge with the merge train strategy.
- Cause the MR to be dropped from the train, for example by pushing a commit to the target branch that conflicts with the train ref, or by letting the train pipeline fail and then fixing the target branch.
- Confirm the MR's head pipeline is now the finished merge train pipeline (the pipeline ref starts with
refs/merge-requests/<iid>/train). - Set auto-merge again. Before this change the MR would stay in "add to merge train when checks pass" and never move; now it is re-added to the train and a new train pipeline starts.
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.