We have concluded investigation on the issue.

All the instances of the issue status flickering can be explained by users running multiple scans with different analysis parameters or in a different environment with the same project key.

Here are the cases that we investigated:

1. Guava project on Peach

The flickering there is best visualized in the Activity tab from 29th of April 2023 until 6th of March 2024. It happened because the same repository google-guava was scanned twice everyday with different analysis parameter. In both cases maven scanner generated Sonar project key out of pom.xml which was scanned twice everyday. Here is the setup of the first scan and here the second one. The parameter that made a difference was -Dsonar.java.source=19. This parameter on this project generated ~2000 new issues that were flickering. The first scan was closing these 2000 issues and the second one (with the parameter) was opening them. To make things even worse this behavior was indeterministic - as the 2 scans were started in parallel but could finish in any order. The fix here was adding a new project key to the second scan and therefore separating these 2 scans to two different projects. Here is the fix.

2. User report on Community

We have a user reporting the same issue on Community - flickering of issue status. Here we don’t have a full context but based on the information shared by user it seems likely that the setup for scanning is incorrect. The user firstly compiles with gcc folderA then runs the scan, then compiles folderB separately and runs a scan again. This results with issue from folderA being closed when issues from folderB are being opened at the same time. The user is very likely using the same project key for both scans as the only parameter passed to scanner is C family related.

3. Another user report on Community

Again, we don’t have a full context here but from what was shared by the user

there might be several results of the same branch but different files

then the flickering of the issues is expected. In both cases (2 and 3) users seem to be using a monorepo.

4. Flickering on public instance of SonarQube

We have a very limited data here but the wrong analysis setup could be an explanation here as the layout of the projects resembles something similar to a monorepo.

In summary it is clear that at least in many cases the issue is scanning the same project many times in a different environment or with different parameters. There maybe some other problems here but after carefully reviewing the code we haven’t encountered any problems. If this issue happens again and will not be explained by the above finding then we might investigate it again with some concrete example.

The suggestion is to make it more visible to our users to not re-use project key for two very different analyses.
Initial idea of was therefore a correct one.

5. Yet another user report on Community

Here in the thread the conclusion is the same - the user uses monorepo in a incorrect way.

This was my thought too. And I have tried that and I didn’t notice anything unusual.

edit: As long as users are using different projectKey users should be fine.

As I mentioned in the second thread, could this come from sequential analyses on different parts of the same project (i.e. a misconfiguration of a mono-repo)?

Like they analyze ts, then .net, then ts again, so issues flip between states at every analysis.

WDYT?