The following discussion from !222317 should be addressed: - [ ] @dskim_gitlab started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/222317#note_3081212575): > I think we should perhaps consider making a clear distinction between `we are checking if we can enable auto_merge` vs `can this MR be merged`. Every time I look at all this `skip_*` it feels very messy and hard to follow when we want to skip and when we don't. I feel the main reason is that we're conflating the two. > > The code doesn't really explain why we're skipping `rebase` check and `conflict` check sometimes. I have to follow the call chain up to understand the reasoning. Should we consider adding a separate method called something like `can_enable_auto_merge` and keep it as pure `mergeable?` check without any skips? I wonder these code should belong to strategy service themselves. :thinking: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/222317#note_3088396554 > Yeah, I see it's called twice. It just seems wasteful to do mergeability checks twice within the same response given that it would execute `merge_to_ref` again which could be expensive. Also, we're calling `mergeable_state?` and `mergeable_git_state?` again even when we have already executed them in `BaseService#availability_details`. Is it really necessary calling `mergeable?` on top? :thinking: > > Perhaps `available_auto_merge_strategies` could just return auto merge strategies based on user permission and other config/status except the mergeability status? We could then check the mergeability only once? Frontend could then use both info to decide what to show? > > It could potentially require a bigger change, but I think this needs to be looked at. I think that's related to my earlier comment about it being hard to follow so perhaps we can consider this as a part of that too. WDYT? https://gitlab.com/gitlab-org/gitlab/-/merge_requests/222317#note_3088396550 > By the way, it's also unclear why we had to set `skip_rebase_check` on EE only so it'd be great if we can consider this as well in the follow up issue.