Assigned Merge Request gets automatically merged without user interaction

Summary

Initial note, searching the CE issue tracker with the template provided links produced 0 results. I did my own searching through DuckDuckGo and GitLab's Issue search, but was not able to find this exact issue. There may still be some simple piece of documentation or oddly worded description I did not find in my filters.

We started noticing some Merge Requests that are assigned to a project Maintainer are automatically merged overnight without any user interaction or API calls being made. Initially we thought the Maintainer was sleep merging, as he has no access tokens generated in his account and the MRs are happening at odd, off-hour times for us.

Last night we confirmed this was happening by having 7 MRs opened. 5 were assigned to our Maintainer and 2 were not assigned. All 5 of the assigned MRs were merged at precisely the same time stamp. The 2 unassigned MRs were left alone and not merged.

NOTE: This issue has also overridden the WIP mechanism and accepted MRs, which seems like shouldn't ever be possible.

I've included the info that I have currently and according to the template. Please let me know if there are any other areas of GitLab that I should check or get info for.

Steps to reproduce

  1. Create new MR
  2. Push some commits to the MR
  3. Assign MR to a maintainer of the project
  4. Wait 24 hours
  5. Observe status of the MR

Example Project

I created an example project, setup the Merge Request method to match ours (Fast Forward only), and assigned it to myself. I am not 100% sure if it will be reproducible here, as we are running CE on-premises in Docker. Time will tell, hopefully it does.

adam.gay/auto-merging-assigned-mr!1

What is the current bug behavior?

The Merge Request is merged, and the UI claims it was accepted by the Maintainer/Assignee

What is the expected correct behavior?

The Merge Request is left alone and requires manual interaction to accept by the Maintainer/Assignee

Relevant logs and/or screenshots

This is a screenshot of our Merged Requests page. The bottom 5 of these have the same, identical time stamp when the mouse is hovered:

screenshot_20190917_125710

Output of checks

This bug happens on an on-premises GitLab CE in Docker.

Results of GitLab environment info

Expand for output related to GitLab environment info 
System information
System:
Current User:   git
Using RVM:      no
Ruby Version:   2.6.3p62
Gem Version:    2.7.9
Bundler Version:1.17.3
Rake Version:   12.3.2
Redis Version:  3.2.12
Git Version:    2.22.0
Sidekiq Version:5.2.7
Go Version:     unknown


GitLab information
Version:        12.2.5
Revision:       09f8edbc29a
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     10.9
URL:            https://code.showseeker.net
HTTP Clone URL: https://code.showseeker.net/some-group/some-project.git
SSH Clone URL:  git@code.showseeker.net:some-group/some-project.git
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers:


GitLab Shell
Version:        9.3.0
Repository storage paths:
  • default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab subtasks ...


Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 9.3.0 ? ... OK (9.3.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK


Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


Gitaly: ... default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1


Checking Sidekiq ... Finished


Checking Incoming Email ...


Incoming Email: ... Reply by email is disabled in config/gitlab.yml


Checking Incoming Email ... Finished


Checking LDAP ...


LDAP: ... LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab App ...


Git configured correctly? ... yes
Database config exists? ... yes

All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes

GitLab config up to date? ... yes

Log directory writable? ... yes

Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
3/1 ... yes

3/2 ... yes

3/3 ... yes

6/20 ... yes

6/22 ... yes

6/23 ... yes

6/24 ... yes

6/26 ... yes
6/27 ... yes

6/28 ... yes
6/29 ... yes

6/30 ... yes

6/31 ... yes

6/32 ... yes

6/33 ... yes
6/34 ... yes

6/35 ... yes

6/37 ... yes
4/38 ... yes

4/39 ... yes
6/41 ... yes

6/42 ... yes
6/43 ... yes

6/44 ... yes
6/45 ... yes

6/46 ... yes
6/47 ... yes

3/49 ... yes
19/50 ... yes

3/51 ... yes

6/52 ... yes
6/54 ... yes

3/55 ... yes
6/56 ... yes

6/57 ... yes
6/58 ... yes

22/59 ... yes
3/60 ... yes

6/61 ... yes
22/62 ... yes

22/63 ... yes
6/64 ... yes

6/65 ... yes
4/66 ... yes

22/67 ... yes
3/68 ... yes

6/69 ... yes

25/70 ... yes

3/71 ... yes

4/72 ... yes

26/73 ... yes

26/74 ... yes

26/75 ... yes

26/76 ... yes

26/77 ... yes

26/78 ... yes

26/79 ... yes

26/80 ... yes

26/81 ... yes

26/82 ... yes

26/83 ... yes

26/84 ... yes

26/85 ... yes

26/86 ... yes

26/87 ... yes

26/88 ... yes

26/89 ... yes

26/90 ... yes

26/91 ... yes
26/92 ... yes

26/93 ... yes
26/94 ... yes

26/95 ... yes

26/96 ... yes

26/97 ... yes

26/98 ... yes
26/99 ... yes

26/100 ... yes

26/101 ... yes
26/102 ... yes

26/103 ... yes
26/104 ... yes

26/105 ... yes
26/106 ... yes

26/107 ... yes
26/108 ... yes

26/109 ... yes
26/110 ... yes

26/111 ... yes
26/112 ... yes

26/113 ... yes

6/114 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.5.3 ? ... yes (2.6.3)
Git version >= 2.22.0 ? ... yes (2.22.0)
Git user has default SSH configuration? ... yes
Active users: ... 16


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Possible fixes

I don't know of any fixes, but our workaround is to simply not assign MRs to anyone. This is OK to keep us from being blocked on development, but for the sake of process and keeping better track automatically of our devs' tasks, having the ability to assign an MR without worry of it automatically merging is preferred.

Edited by Adam Gay