"Add to merge train when checks pass" incorrectly shown instead of "Re-add to merge train" when merge train pipeline fails
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
When a merge train pipeline fails (e.g. due to a transient error like a 503), the merge request widget sometimes incorrectly shows "Add to merge train when checks pass" instead of "Re-add to merge train". This causes the MR to hang indefinitely — it waits for a new pipeline to pass before it can be re-added to the train, even though the intent is simply to retry the failed merge train pipeline.
This is intermittent. The same MR, in what looks like the same state, will sometimes show the correct "Re-add to merge train" button and sometimes the wrong one. We do not have a reliable way to reproduce it yet, so the steps below describe the conditions under which it has been seen rather than a deterministic recipe.
Steps to reproduce
Note: These steps do not reliably reproduce the bug. Following them may show the correct button. Expect to need several attempts, and possibly several different MRs, before hitting the faulty state.
- Have an MR on the merge train.
- The merge train pipeline fails due to a transient/unrelated reason (e.g.
curl: (22) The requested URL returned error: 503). - The MR is removed from the merge train.
- Observe the auto-merge widget — sometimes it shows "Add to merge train when checks pass" (MWCP variant) instead of "Re-add to merge train" (merge train variant).
- When the wrong variant is shown, clicking the button puts the MR into "merge when checks pass" mode, which waits for the head pipeline to pass — but the head pipeline is the failed merge train pipeline, so it never re-enters the train.
Expected behavior
When the head pipeline is a failed merge train pipeline, the widget should always show "Re-add to merge train", allowing the user to immediately re-add the MR to the train without needing to run a new full pipeline first.
Actual behavior
Some of the time the widget shows "Add to merge train when checks pass", which causes the MR to hang. The user is stuck unless they:
- Cancel auto-merge and hope the button changes to "Re-add to merge train" on the next attempt, or
- Trigger a brand new (full) pipeline and wait for it to pass.
Workaround
Cancel auto-merge, then click "Set to auto-merge" again and hope it presents "Re-add to merge train". Because the behavior is intermittent, this often works after one or two attempts. Alternatively: cancel auto-merge, trigger a new pipeline, wait for it to pass, then re-add to the merge train.
Additional context
- This appears to happen roughly 1 in 3 MRs for some users, which matches the intermittent nature of the bug. It is not consistent per user, per project, or per MR.
- No reliable reproduction is known yet. Timing (how soon after the pipeline failure the widget is loaded or the button is clicked) seems to matter, which makes it hard to trigger on demand.
- The suspected root cause is a delay or race condition in the mergeability check — when the user clicks the button before the check has recognized that the head pipeline is a merge train pipeline, it falls back to the MWCP variant. This would explain why the bug only shows up some of the time.
- Manual job-level retries are disabled on completed merge train pipelines (by design), so retrying the failed job is not an option.
- Related MRs where this was observed: !252202 (merged), !248460 (merged)
Possible fix direction
- Do not offer "Add to merge train when checks pass" when the head pipeline is a failed merge train pipeline.
- Instead, always offer "Re-add to merge train" in that scenario.
- Consider disabling the "Set to auto-merge" button (or showing a loading state) while the mergeability check is still in progress, to avoid presenting the wrong variant.
- Since the bug cannot be reproduced on demand, a first step may be to add logging or instrumentation around which auto-merge variant is selected, so the race can be confirmed from real data.