"Merge" button silently and randomly fails

Summary

I've noticed that clicking the "Merge" button on an MR may silently and randomly fail.

At a wild guess, this occurs maybe 1 time in 10. GitLb acts like it's merging, so I often move on to my next task and don't notice until some time later that the merge failed. GitLab displays no feedback when this happens; it simply updates the MR webpage to show "Open."

This is NOT the result of a merge conflict or similar; all I have to do is click "Merge" again, and it works.

In case it's relevant: This occurs with Renovate MRs, so it normally happens as I'm quickly reviewing and merging several MRs in a row.

Steps to reproduce

  1. Click "Merge" on an MR.
  2. Get (un)lucky.

What is the current bug behavior?

Clicking "Merge" randomly and silently fails.

What is the expected correct behavior?

Clicking Merge always reliably succeeds - OR, if not, GitLab at least displays a clear message as to what's wrong.

Relevant logs and/or screenshots

Today, I was able to capture this within the dev tools network tab:

First, an HTTP POST to https://gitlab.com/mygroup/myproject/-/merge_requests/1234/merge

Sanitized payload:

{
  "sha": "xxx",
  "should_remove_source_branch": true,
  "skip_merge_train": false,
  "squash": false
}

Reply:

{"status":"failed"}

Immediately afterwards, HTTP GET to https://gitlab.com/mygroup/myproject/-/merge_requests/1234.json?serializer=basic

Sanitized reply:

{
    "title": "fix(deps): update package monorepo to ^1.234.0",
    "merge_status": "checking",
    "merge_error": null,
    "state": "opened",
    "source_branch_exists": true,
    "rebase_in_progress": false,
    "should_be_rebased": false,
    "milestone": null,
    "labels": [],
    "assignees": [],
    "reviewers": [],
    "task_status": "0 of 1 checklist item completed",
    "task_status_short": "0/1 checklist item",
    "lock_version": 0
}

Output of checks

This bug happens on GitLab.com.

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖