Merge trains and auto merge parameters can become inconsistent
Summary
In a recent customer issue see zendesk link (internal) and this sentry error (internal), we found that merge trains can get stuck with errors of the form
undefined method `username' for nil:NilClass
new(gitlab_user.username, gitlab_user.name, gitlab_user.commit_email_or_default, Gitlab::GlId.gl_id(gitlab_user), gitlab_user.timezone)
^^^^^^^^^
lib/gitlab/git/user.rb:9:in `from_gitlab',
lib/gitlab/gitaly_client/operation_service.rb:400:in `user_rebase_to_ref',
lib/gitlab/git/repository.rb:965:in `block in rebase_to_ref',
lib/gitlab/git/wraps_gitaly_errors.rb:7:in `wrapped_gitaly_errors',
lib/gitlab/git/repository.rb:964:in `rebase_to_ref',
...This gitlab_user value comes from merge_request.merge_user, where merge_request is the merge request whose train car is being refreshed.
This merge_user is part of the auto merge parameters that get cleared on merge and abort/cancel.
The fact that the user is nil probably means the merge got cancelled without destroying the associated train car.
Steps to reproduce
See #490708 (closed) for an example of how this can happen.
Example Project
What is the current bug behavior?
What is the expected correct behavior?
Relevant logs and/or screenshots
Output of checks
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)