<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary Trying to "merge when pipeline succeeds" via the API, immediately after opening a MR, fails with "405 Method not allowed". <!-- Summarize the bug encountered concisely. --> ### Steps to reproduce 1. `POST /projects/:id/merge_requests` 1. Use the resulting MR iid to run `PUT /projects/:id/merge_requests/:iid/merge` with `merge_when_pipeline_succeeds=true` ### Example Project We're using [CML](https://github.com/iterative/cml) to automatically create merge requests with new data that is pulled in daily ([example](https://gitlab.com/dacs-hpi/bp21/covmobil/-/jobs/2147697864)). We'd like to automatically mark them as "merge when pipeline succeeds", and I opened a PR to CML that adds this behaviour: https://github.com/iterative/cml/pull/903 <!-- If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report. If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version. --> ### What is the current *bug* behavior? It responds `405 Method Not allowed` <!-- Describe what actually happens. --> ### What is the expected *correct* behavior? It responds `200 OK` <!-- Describe what you should see instead. --> ### Relevant logs and/or screenshots <!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise. --> ### Output of checks <!-- If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com --> #### Results of GitLab environment info this bug happens on gitlab.com ### Possible fixes on my end, I can fix it by adding a 20secs timeout between the two API calls. this makes me think there's some race condition with a background worker on Gitlab's side that hasn't yet executed.