<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal When a merge request is set to merge when the pipeline succeeds, a system note is added to the MR:  An automatic merge can be aborted when: - One or more threads are (re-)opened before the merge happens - Merge conflicts are introduced in the target branch - The pipeline fails - Any other situations? It would be useful if system notes were added for each of these cases. Whenever an automatic merge is aborted, the reason _why_ would be recorded. This would also help to clarify what steps need to be taken to fix it. Currently, if a merge request is set to merge when the pipeline succeeds, there's no notification of the failure to merge (except _maybe_ a failed pipeline email, though it doesn't obviously convey that the merge was aborted). This means that a merge request you thought got merged a while ago in fact still isn't merged, and it's not obvious why. With system notes (and notifications?) at least authors would be able to easily determine why (or react in a timely manner). ### Questions - What should happen if an MR is set to MWPS, and some time before the pipeline completes, a thread is opened (or any other case preventing the merge)? Should a system note/notification be sent when the thread is opened, or later when the merge is finally aborted? - Similarly, what should happen if the situation preventing the MWPS from occuring is then resolved, e.g., the thread is closed, before the merge occurs? <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. --> <!-- Label reminders Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->