Race condition causes commits to be silently dropped during rapid push-and-merge operations

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

Race condition causes newly pushed commits to be omitted from merged branches when using rapid push-and-merge commands, resulting in incomplete merges.

Steps to reproduce

Prerequisites:

  • GitLab 18.1 self-managed
  • Existing merge request with 1 approved commit
  • Using glab CLI

Steps:

  1. Create an MR with 1 commit and get it approved
  2. Push a 2nd commit to the MR
  3. Immediately merge using: git push && glab mr merge --auto-merge=false -y <MR ID>
  4. Repeat multiple times

Result: Occasionally, the merge succeeds but the 2nd commit is missing from the merged branch. Only the 1st commit gets included.

What is the current bug behavior?

When rapidly pushing and merging, GitLab sometimes processes the merge before the newly pushed commit is fully added to the branch. The merge succeeds, but the latest commit is silently dropped. No error or warning is shown.

The customer initially thought this was the approval bypass issue again, but discovered the newest commit was completely missing from the merged branch. It appears the glab mr merge command executed before GitLab finished processing the push.

What is the expected correct behavior?

GitLab should not merge until all pushed commits are fully processed and added to the MR. The merge should either:

  • Wait for the latest commit to be processed, then include all commits in the merge, OR
  • Reject the merge with an error saying the branch is still being updated

GitLab should never merge some commits while silently dropping others. This causes:

  • Missing code changes in production
  • Developers thinking their changes were merged when they weren't
  • Lost bug fixes or features
  • Confusion about what's actually in the target branch
Edited by 🤖 GitLab Bot 🤖