we are using sonarqube Enterprise Edition v2025.1.
We are facing the following problem:
Our Quality Gate checks that there are no Major issues in New Code (also other things are checked but not of relevance for this issue). We have now several occurrences where for some unknown reason new Major issues appear for unchanged (not new!) code. There seem to be some rules that don’t detect issues reliably. We noticed that behavior for rule java:S6204 for example. It suddenly produced a new issue in a completely unchanged file (also the code in the gui does not show as new and it is not part of the code shown as “New Lines” under Measures/Size.
Now we have two different behaviors:
In branch A we first run a scan for version 10 that does not find the issue. Afterwards we run a scan for version 11 in the same branch. Now the issue is detected. The file is unchanged but the Quality Gate fails because of one new Major issue (although it is not in New Code)
In branch B we run a scan for version 10. Then we run a scan for version 11 in branch C (which is newly created with that scan) and give branch B as reference branch. At that time branch B contains the same scan as branch A in example 1) after the first scan of version 10. Nevertheless, in this scenario the new issue is also found, the same code is shown as new as in example 1) where both scans are done in the same branch, but the Quality Gate does not fail because it is correctly identified as not being in changed code.
As the Quality Gate is clearly configured to identify only issues in New Code, it should not complain about the issue in both cases.
In addition I consider it as a bug that some rules seem to not always detect all issues properly and suddenly there pop up new issues although there has been no change.
We consider both as a bug that should be fixed. Not sure if it is somehow related…
Thanks for providing the rule ID. That’s very helpful.
This guide describes several scenarios for legitimately new issues in old code. In addition, I think it’s worth considering that this rule kicks in based on the version of Java you’re targeting. Is it possible you upgraded Java (or your target Java version) between the two analyses?
thanks for the feedback! I am aware of the cases where new issues in old code might be expected, but in the two cases we noticed this is not the case.
This one issue is found in a file where we have two nearly identical code lines where the issue is also detected. But in these two lines it is always found (in version 10 and in version 11). In the third line which contains the same Stream.collect(Collectors.toList()) the issue is only suddenly identified in version 11.
And I have one more example of a rule where we had a new issue although the code and all related things seem to be unchanged: java:S4165
And one more question: Can you explain why Sonar complains about those new issues in old code in some branches and does not in others? If my Quality Gate is configured to have 0 Major issues in New Code, why does it complain about an issue in old code (even if the issue is new)??
Not easily, but I can show you a screenshot of the file where you can see all three issues. The one in the middle, in line 49 is only suddenly found later. The other two have already been there.
I guess you’re referring to this scenario?
Yes, the scenario that I described above.
Compared to the reference branch (B), it’s not new code in branch C.
Correct. But it is also not new code in scenario 1 where the scan is done in the same branch. In both cases the last scan of version 10 is the base to identify changed code. Only difference is that in case 1 the reference is in the same already existing branch, and in case 2 the reference is in a different branch.
As in both cases the file is not new code compared to the reference, in both cases the issue should not affect the Quality Gate.
I suppose the one in the middle is the new one? Can you click in the left margin to verify that the blame dates on those issue lines are what you expect? (And maybe share the dates? )
yes the one in the middle is the new one. Usually we are doing shallow clone so we don’t have blame information available. To test if the issue is related to that I did a testscan with full clone history. Now I see the blame information also in Sonar.
The new issue in line 49 is still shown as New. The blame information shows the same dates as Github does.
The date for line 49 is shown in the screenshot. Line 45 was last changed in 2021, line 52 in 2020.
Then all bets are off. You get a warning in the analysis log, and we’ve got warnings about shallow clone scattered throughout the docs because if you’re doing a shallow clone, the information analysis needs to properly date issues simply isn’t available.
Yes. Reanalyzing with the SCM data available isn’t going to re-date the issue. The issue was dated when it was raised initially, and that isn’t going to change.
So, dates aside, we’re still left with this question:
Is this reproducible? If so, can you reproduce it and provide the analysis logs for both runs?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
I did some more tests and created a completely new project on our testserver. All scans there done without shallow cloning. It shows exactly the same dates for the three issues as I reported above and the behavior is also identical and reproducable.
It finds the issues in lines 45 and 52 with one version, and suddenly with next version it also identifies an issue in line 49.
Line 49’s date is Apr 29 2020 in the case where the issue is identified as well as in the case where the issue is ignored.
I can send you the logs. Do you want me to enable debug mode? Where can I upload them as I don’t want to put them here readable for eveyone?
And one more question: Would it be enough to provide the full history for the respective github branch or do we need full history for the whole repo to get this date issue fixed? And I would be interested in: what exactly does not work properly if the github history is not complete.
please find two logs attached. One from a run that only identifies 2 issues in the file. The other one from the run that finds 3 issues in the respective file.
Thanks for the logs. They show that this is not an apples-to-apples comparison:
2 issues:
[Thread-14] INFO org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncher - 3 languages detected in 839 preprocessed files
[Thread-14] INFO org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncher - 715 files ignored because of inclusion/exclusion patterns
...
[Thread-14] INFO org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncher - 839 files indexed
...
[Thread-14] INFO org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncher - Did not optimize analysis for any files, performed a full analysis for all 412 files.
...
[Thread-14] INFO org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncher - Analyzing 4904 functions to detect bugs.
3 issues:
[Thread-14] INFO org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncher - 3 languages detected in 851 preprocessed files
[Thread-14] INFO org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncher - 720 files ignored because of inclusion/exclusion patterns
...
[Thread-14] INFO org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncher - 851 files indexed
...
[Thread-14] INFO org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncher - Did not optimize analysis for any files, performed a full analysis for all 424 files.
...
[Thread-14] INFO org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncher - Analyzing 4972 functions to detect bugs.
I asked for the logs, because I expected to see something like this, which does appear in both logs: Unresolved imports/types have been detected during analysis. Enable DEBUG mode to see them.
This line tells us that analysis is missing information it needs to be thorough. At a guess, it’s missing more information in the 2-issue log than in the 3-issue run.
So the next step here is to figure out what’s different between how the two analyses are run, and bring them to parity.
what do you mean by this? Of course the numbers are different, because it is different versions of the software as already mentioned at the beginning. In my example the one with 2 issues is version 10 of our software, the one with 3 issues is version 11. In reality the versions from the example logs are 83 and 84. There have been code changes in 84 but nothing that should cause the new issue in the unchanged file.
I will do scans in DEBUG mode now to see if there is a difference.
if I do DEBUG mode scan and search for the respective filename, there is one occurrence that only appears in the case where not all issues are reported.
The following entry can be found in the log in this case:
[Thread-14] DEBUG org.sonarsource.scanner.lib.internal.facade.forked.ScannerEngineLauncher - Use of preview features:
Cannot infer type argument(s) for map(Function<? super T,? extends R>)
somehow it looks like. But I am doing exactly the same in both cases, except for different version of the software….
I could start removing some of the differences from code to find out what exactly causes the difference at the end, but this might be difficult because I am not a developer and the software has to be still compilable.
for building we have a Jenkinsjob which is based on a Jenkinsfile. This does checkout and starts the maven build. In both cases exactly the same Jenkinsfile is used. So we call exactly the same commands. Only difference is the commit that is checked out from github.
In addition we do the build on the same machines, so I have no idea what could be different on the build side. Everything there is controlled by us and I know the process very well…
I really don’t know what to tell you. The difference in issue detection is related to the difference in data available to analysis. Something is different.
)
