<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=121576) </details> <!--IssueSummary end--> The following discussion from !21026 should be addressed: - [ ] @nick.thomas started a [discussion](https://gitlab.com/gitlab-org/gitlab/merge_requests/21026#note_263611097): (+1 comment) > When making the rebase asynchronous, I tried to move the enqueuing method out of the model and into a class method of the worker or service. I was defeated by the fact that I was using pessimistic locking and other database-level stuff though. > > Since we're doing none of that here, WDYT to reducing the size of `app/models/merge_request.rb` slightly by moving this to worker or service? > > It also means less code wrapped in a `rubocop: disable CodeReuse/ServiceClass` block. ---- This is to reduce the size of the `MergeRequest` model and move the responsibility out of the model as well. Based on the discussion above, in order to move the `MergeRequest#check_mergeability` out of the model, we also need to take this into consideration: > This `MergeRequest#check_mergeability` method is also being called in `MergeRequest#mergeable?`. If we move this logic out, the `#mergeable?` method will then need to call that service class again which will require us to disable `CodeReuse/ServiceClass` cop. It seems more refactoring needs to be done aside from moving `#check_mergeability`.