We had this issue 2 times before this year on other projects.
We currently have no idea yet what causes this issue. I´ll try to do the patch-update from 2026.1.2 to 2026.1.3. And we will update the SonarQube-Gradle-Plugin.
Unfortunately, it’s entirely possible to get additional issues after merge. Why? Well PR analysis only reports on the lines changed in the PR. But changes can have wide-ranging impacts.
In your case, all 5 issues in your screenshot are from the same rule which has to do with accessing the value of an Optional. Did your change involve modifying the return value of a function? To maybe now return an Optional where it didn’t before? Because doing so would potentially impact every place that function is called.
No change in method-signatur or something like this. Just an additional filter.
When we look at the five new medium issues they are related to classes in architecture-layers below. So the modified method is not called by the two classes which show up with new medium issues.
To my best knowledge this is also ensured by our module-structure. The two classes which show up with new medium issues are part of the -core-module. This module can´t access classes within the -web-module where two lines of code were modified. (Only the other way round is allowed. Classes of the -web-module can access classes from the -core-module.)
What else changed between the 5-issue analysis and the previous analysis on the same branch? Any changes to analysis configuration? … The build? (Including e.g. the version of Java on the build agent.)
Same Sonar-, Java-, Gradle, Sonar-Gradle-Plugin-version. No changes to Quality Profile or Quality Gate. Same / not modifed Jenkins shared library. We did a patch-update of our Jenkins instance including plugins a week ago.
We noticed a similar issue end of march in another project. (This time it was after updating Sonar from 2025.4.4 to 2026.1.0.)
And had this a third time back in february. The february issue was after onboarding a existing large project into Sonar. For this project the solution was to delete it from Sonar and import / onboard it again.
Hm. You sound pretty confident there must be a good reason for this behaviour of Sonar? Even when there´s no obvious one (yet) …
As far as you remember - have there been always good reasons for such kind of behaviour?
Yes, there is usually a reason for it. Sometimes even a good one!
Issues are dated for when they’re found except under certain circumstances. So the real question is not “Why is this issue found now?” but “Why wasn’t this issue found previously?”
Looking back through this thread and the backdating conditions… All the issues you question came from the same rule. If the rule had just been added to the profile, the issues would/should have been backdated… unless the SCM data wasn’t available to the analysis? Do you still have the analysis log from that run?
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.
We don’t know what condition it failed on (you could probably find it in a mouseover on the Activities tab.) It could be that the analysis reduced overall issues (-20) but still added some new ones (+13 gets us to a net -7) which would have failed a “no new issues” criterion, or failed because of coverage or duplications.
Thanks for pointing me to the CI-logs. This may show a valid reason…
There´s been an issue with creating lock file /.config/jgit/config.lock
This may be the reason why SonarQube had issues detecting new code.
In detail:
Task :sonar
Unresolved imports/types have been detected during analysis. Enable DEBUG mode to see them.
Use of preview features have been detected during analysis. Enable DEBUG mode to see them.
Use of preview features have been detected during analysis. Enable DEBUG mode to see them.
Couldn’t flush user prefs: java.util.prefs.BackingStoreException: ?/.java/.userPrefs/org create failed.
Couldn’t flush user prefs: java.util.prefs.BackingStoreException: ?/.java/.userPrefs/org create failed.
Unresolved imports/types have been detected during analysis. Enable DEBUG mode to see them.
Use of preview features have been detected during analysis. Enable DEBUG mode to see them.
Use of preview features have been detected during analysis. Enable DEBUG mode to see them.
Use of preview features have been detected during analysis. Enable DEBUG mode to see them.
Unresolved imports/types have been detected during analysis. Enable DEBUG mode to see them.
Use of preview features have been detected during analysis. Enable DEBUG mode to see them.
Binary paths (sonar.java.binaries) are empty. .class files can not be looked up to facilitate caching.
Couldn’t flush user prefs: java.util.prefs.BackingStoreException: ?/.java/.userPrefs/org create failed.
Creating lock file /.config/jgit/config.lock failed
java.io.IOException: Creating directories for /.config/jgit failed
at org.eclipse.jgit.util.FileUtils.mkdirs(FileUtils.java:421)
at org.eclipse.jgit.internal.storage.file.LockFile.createLockFile(LockFile.java:172)
at org.eclipse.jgit.internal.storage.file.LockFile.createLockFileWithRetry(LockFile.java:165)
at org.eclipse.jgit.internal.storage.file.LockFile.lock(LockFile.java:146)
at org.eclipse.jgit.storage.file.FileBasedConfig.save(FileBasedConfig.java:201)
at org.eclipse.jgit.util.FS$FileStoreAttributes.saveToConfig(FS.java:761)
at org.eclipse.jgit.util.FS$FileStoreAttributes.lambda$4(FS.java:433)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Cannot save config file ‘FileBasedConfig[/.config/jgit/config]’
java.io.IOException: Creating directories for /.config/jgit failed
at org.eclipse.jgit.util.FileUtils.mkdirs(FileUtils.java:421)
at org.eclipse.jgit.internal.storage.file.LockFile.createLockFile(LockFile.java:172)
at org.eclipse.jgit.internal.storage.file.LockFile.createLockFileWithRetry(LockFile.java:165)
at org.eclipse.jgit.internal.storage.file.LockFile.lock(LockFile.java:146)
at org.eclipse.jgit.storage.file.FileBasedConfig.save(FileBasedConfig.java:201)
at org.eclipse.jgit.util.FS$FileStoreAttributes.saveToConfig(FS.java:761)
at org.eclipse.jgit.util.FS$FileStoreAttributes.lambda$4(FS.java:433)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
[Incubating] Problems report is available at: file:///var/lib/jenkins/workspace/ITPE4U_pe4e_master/build/reports/problems/problems-report.html
Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
You can use ‘–warning-mode all’ to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
For more on this, please refer to
in the Gradle documentation.
BUILD SUCCESSFUL in 2m 17s
1 actionable task: 1 executed
[Pipeline] }
[Pipeline] // withSonarQubeEnv
[Pipeline] timeout
Timeout set to expire in 5 min 0 sec
[Pipeline] {
[Pipeline] waitForQualityGate
Checking status of SonarQube task ‘da57e7a6-d1d3-4e1f-9d2a-83005c3a4996’ on server ‘SonarQube’
SonarQube task ‘da57e7a6-d1d3-4e1f-9d2a-83005c3a4996’ status is ‘IN_PROGRESS’
SonarQube task ‘da57e7a6-d1d3-4e1f-9d2a-83005c3a4996’ status is ‘SUCCESS’
SonarQube task ‘da57e7a6-d1d3-4e1f-9d2a-83005c3a4996’ completed. Quality gate is ‘ERROR’
That means your logs are unusually terse by default. Could you add