Skip to content

MergeTrain::Car Target branch not getting updated when the initial target branch is deleted

Summary

A GitLab user couldn't add their Merge Request to their project's Merge Train. This happened because, at the moment the MR was added to the train, the target branch was deleted. This left the Merge Train Car in an active state and targeting the wrong branch.

Slack conversation (Internal)

affected MR: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/10759

Steps to reproduce

  • Create a merge request in a project where merge trains are enabled. Make sure it targets a different branch from the project's default
  • Add the MR to the train
  • Delete the target branch
  • The merge request should now target the main branch and the Train should've been aborted
  • Find the Car from your rails console, and check its' target branch. It should point to the deleted branch and have a MergeTrains::Car::ACTIVE_STATUSES status.

Screenshot_2024-09-05_at_12.21.16_PM

What is the current bug behavior?

The train is aborted but the car is left in an active state and targeting the wrong branch

What is the expected correct behavior?

The car should be inactive and targeting the correct branch

Possible fixes

based on the system note: Tarun Vellishetty aborted automatic add to merge train because target branch was changed Sep 4, 2024, 6:30 AM

The request to abort used: AutoMerge::AddToMergeTrainWhenPipelineSucceedsService

We need to destroy the merge train car in AutoMerge::AddToMergeTrainWhenPipelineSucceedsService#abort similar to how we do in AutoMerge::MergeTrainService#abort.

AutoMerge::AddToMergeTrainWhenPipelineSucceedsService seems to be built with the assumption that the abort will only happen prior to the train car being created, but we see that MergeRequests::UpdateService#handle_target_branch_change can abort a merge request after it's already been added to the train when the strategy is Add To Merge Train When Pipeline Succeeds.

The abort is called from MergeRequests::UpdateService#handle_target_branch_change as traced back based on the abort reason.

Workaround

The user needs to create a new merge request.

Edited by Allison Browne