- versions used: SonarQube 9.3
We recently upgraded to SonarQube 9.3 Dev edition.
We have observed that after an analysis, we have three blocker bugs in our “new code” tab due to rule java:S2095, but the commit that introduced that is dated from 2016. Our new code period of course is not that long. See screenshot below:
Is this an expected behaviour, or is this maybe a bug introduced in the latest release? Note that before we were using 9.2.4 and we saw nothing like this.
Thanks in advance and feel free to contact me in case further information is needed.
Welcome to the community!
Sorry about the missing accent. I’m on an AmE keyboard.
Rule S2095 is about closing resources. This is a classic example of a rule that can result in new issues in old code because it relates to multiple code locations: the location where the resource is opened and the location where it is (or was) closed.
If yesterday the code to close it existed, but I delete it today, the next analysis will raise a new “unclosed” issue on the location where the resource is opened. And there won’t be much visible in SonarQube that’s “new” related to this issue because we have no way to indicate that there were deletions. (And really, we don’t even try to detect them.)
Does this make sense in your context?
(Copy-pasted the ú from a Windows-1252 list so I hope this website doesn’t mess it up…)
Does the file with the new-but-actually-old issues happen to have new code in the same file that was recently committed? I reported an issue (Configure SQ to give more weight to block move info?) where recently-committed code was doing the same thing as older code with issues already raised, such that the hashes of the flagged code matched. The code was inserted in the middle of a method, and it pushed everything else down, so that the SQ analysis got confused about which issue was which, and misaligned them. Therefore, it thought that the new code was an old issue, and so it was like “musical chairs” where the last issue didn’t correspond to any existing issue, and so SQ said it was a new issue – even though the code was actually several years old.
Not really, the file itself has remained untouched for several years now
Thanks for the answer. That completely makes sense to me. I’ll double check on Monday anyway and will confirm you whether that’s the case
Thanks a lot!
Hi again Ann. That was exactly the case then, although was a bit challenging to identify the commit that raised the issue. Many thanks in any case!!!