A team renamed a file in a pull request.
The file contains a vulnerability and the decorator adds comment to the PR.
The team ignores the comment and completes the PR.
In the SonarCloud page for the project’s master branch the New code section does not display a vulnerability.
To be honest, I think there is a case to make for each behavior (“rename does not mean new code” vs “rename does mean new code”) but not one behavior in one place, and the other behavior in another place.
You’re right: SonarCloud attempts to detect files that are renamed in a long lived branch so that issues in the file before getting renamed are tracked and matched in the new file after the rename.
This is not done with P/Rs when comparing issues between the P/R and its target. It’s mostly because of the technical complexity that would introduce but also because we try to rely as much as possible on the SCM to tell us what was modified - it might be more transparent to the user to have results consistent with the SCM.