Skip to content

Backport 17-2: handle empty repository.ff_merge

What does this MR do and why?

%17.2 Backport of !162077 (merged)

Properly handle empty repository.ff_merge in FromTrainRef merge strategy

The Gitaly API returns an empty response instead of an error if the ref update portion of the fast-forward merge fails due to a race with another ref upate. This could cause a merge request to incorrectly appear merged if the target branch got updated while merge train was performing a fast-forward merge.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

You can simulate the race condition as follows:

  1. Review the gitaly contribution guide
  2. In your GDK's gitaly source, modify internal/gitaly/service/operations/ff_branch.go to add a time.Sleep(1 * time.Minute) just before the call to s.updateReferenceWithHooks(...), run make build in the gitaly directory and restart gitaly with gdk restart gitaly.
  3. In a project, enable merge trains and the fast-forward merge method
  4. Create a merge request
  5. Start the merge train
  6. Wait for the pipeline to pass
  7. 10-30 seconds after the pipeline passes, push a change to the target branch
  8. If the push succeeds, proceed to validate results. If the push fails, you need to try again with a new MR

Expected results:

  • Without this change, the merge succeeds but the MR's code does not land on the target branch
  • With this code, the merge should fail. The MR stays open and gets removed from the train.

Merge request reports

Loading