<!--- 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 A merge request which should be covered by the security policy was able to merge without fulfilling it, potentially due to a merge request chain not refreshing the policy after the merge request before it was merged. #### Situation Two merge requests (MR). MR1 : branch-1 targeting main MR2: branch-2 targeting branch-1 (Set to depend on MR1 being merged first) A security policy project is in place covering all merge requests within the project to protected branches (main). It is strictly enforced and requests 2 approvers. There are no restrictions on merges or merge requests between unprotected branches. So if MR2 was not set to depend on MR1 being merged, that MR would be possible to merge. When MR1 was merged into main, MR2 was re-targeted to main and the dependency of MR1 being merged was fulfilled. The approval rules defined by the security policy was however not updated thus not enforcing approvals and the MR was merged without approvals. We noticed that the MR reported being able to merge without approvals. We tried refreshing the page to get it to notice that the policy had changed however it did not. We thought it would block the merge when the merge button was clicked and refresh its policy. However, it did not. It merged it without approvals. ### Steps to reproduce We have not been able to reproduce it. We have used the chaining of MR's before and not seen the problem, and we have also not been able to reproduce it. It seems like we hit some kind of edge case that is difficult to pinpoint or it could be sporadic. ### What is the current _bug_ behavior? The MR which should be covered by the project's security policy project should prevent merge without the required number of approvals however after retargeting to main, it allowed merging without approvals. ### What is the expected _correct_ behavior? When the MR is retargeted to it should update its merge requirements (in this case 2 approvers) to match those of the branch it is being merged into. ### Relevant logs and/or screenshots The MR was merged to main without approvals. It doesn't even write that it was retargeted. (We are pretty sure it was retargeted to main but even if it wasn't it, should still have been covered by the security policy and thus require approvals. Being covered by the policy would have just been from the time of creating the MR and not from retargeting.) {width=408 height=75} How it looks in other MRs. When the dependent MR was merged the MR was retargeted to main and where it would require approvals and after being approved it can be merged. {width=900 height=417} <!--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, uncomment below--> <!--This bug happens on GitLab.com--> <!--and uncomment below if you have /label privileges--> <!--/label ~"reproduced on GitLab.com"--> <!--or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not--> #### Results of GitLab environment info <!--Input any relevant GitLab environment information if needed.--> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (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\\\`) </pre> </details> #### Results of GitLab application Check <!--Input any relevant GitLab application check information if needed.--> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (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) </pre> </details> ### Possible fixes <!--If you can, link to the line of code that might be responsible for the problem.--> ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!--If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"`-->