Issue keeps on switching between statuses without any relevant changes

Hi,

we are using SonarQube 9.9.1 and observe a strange behaviour regarding a specific issue.

The message is ‘Replace this “Map.get()” and condition with a call to “Map.computeIfPresent()”’ in a Java file, the affected line is “WeakReference reference = loaders.get(key);”

The file including this line was created in April 2023 and not changed since then.

It by now exists on the main branch (master) and on a release branch which was created afterwards from the main branch. On both branches it keeps on switching its status, but in a different way.

On the release branch this issue keeps on switching between FIXED/CLOSE and OPEN: (output shortened)

June 22, 2023 at 3:30 PM
Created by XXX

July 12, 2023 at 12:50 PM	
Resolution changed to FIXED
Line number removed from issue (was 49)
Status changed to CLOSED (was OPEN)

July 12, 2023 at 1:53 PM	
Resolution removed (was FIXED)
Status changed to OPEN (was CLOSED)

July 14, 2023 at 11:24 AM	
Resolution changed to FIXED
Line number removed from issue (was 49)
Status changed to CLOSED (was OPEN)

July 14, 2023 at 4:07 PM	
Resolution removed (was FIXED)
Status changed to OPEN (was CLOSED)

On the main branch, the issue keeps on switching between WONTFIX/RESOLVED and FIXED/CLOSED: (output shortened)

April 21, 2023 at 6:27 PM
Created by XXX

April 25, 2023 at 6:10 PM	
The issue has been copied from branch '#7720' to branch 'master'

August 15, 2023 at 5:31 PM	
Resolution changed to FIXED (was WONTFIX)
Line number removed from issue (was 49)
Status changed to CLOSED (was RESOLVED)

August 16, 2023 at 1:22 PM	
Resolution changed to WONTFIX (was FIXED)
Status changed to RESOLVED (was CLOSED)

August 16, 2023 at 2:33 PM	
Resolution changed to FIXED (was WONTFIX)
Line number removed from issue (was 49)
Status changed to CLOSED (was RESOLVED)

August 17, 2023 at 11:18 AM	
Resolution changed to WONTFIX (was FIXED)
Status changed to RESOLVED (was CLOSED)

The behaviour on the release line branch is very annoying, as the issue keeps on popping up, without any changes. I have no idea how to explain this behaviour to the developers.

Does anybody please have an idea what is going on here and how to keep the issues as WONTFIX? (We don’t want to touch this code.)

Thanks!

Regards,

Carsten

Hi @Carsten_HB,

Thanks for reaching out and for the information that you provided!

We’re already aware of an issue that might be related.
Unfortunately, it’s not very easy to reproduce, so the investigation might take a while.

In the meantime, feel free to share any other information or updates from your side that you think it might be relevant.

I’ve opened a ticket to gather all the relevant information.

1 Like

Hello,

we are currently investigating the same symptom here (though maybe not caused by the same reason), and have developed a theory for our setup, that I would like to share, hoping that it helps the investigation:

We are running SonarQube Developer Edition Version 9.9 (build 65466).

ATM, we have a gitlab pipeline which runs SonarScanner a few times in a row (which I know does not make sense in a productive system, so bare with me here) for different parts of a repo like so:

foo:
  script:
    - .sonar/build-wrapper-linux-x86/build-wrapper-linux-x86-64 --out-dir .sonar/bw-output gcc folderA/foo.cpp -o foo.out
    - sonar-scanner -Dsonar.cfamily.build-wrapper-output=.sonar/bw-output -X

bar:
  script:
    - .sonar/build-wrapper-linux-x86/build-wrapper-linux-x86-64 --out-dir .sonar/bw-output gcc folderB/bar.cpp -o bar.out
    - sonar-scanner -Dsonar.cfamily.build-wrapper-output=.sonar/bw-output -X

and what we observe is, that when running that pipeline, sonar-scanner reports the findings in foo and then when receiving the resutls for bar changes the findings in foo to “Fixed”.

Apparently SonarQube does not seem to be happy when there are several scan results for the same branch but different files are arriving in a short period of time (~1min in our case).
This is quite artificial in our setup, but can of course still happen when there are different build jobs running in parallel on the same branch.

Does this make any sense to you, or is this something completely different in our case?

Many thanks

Sasha

3 Likes

Hi Sasha,

we as well trigger several (6) analyses in a row, as we are working with a monorepo including several projects. So your observations might be related to our problem.

As we have 8 build agents running analyses on several branches in parallel, there might be several results of the same branch but different files and as well of the same files on different branches arriving in a short period of time.

Thanks!

Carsten

1 Like

Hi @Carsten_HB,

we are trying to reproduce the issue you are experiencing on our side. Answering below questions could help us narrow down the problem.

  1. Have there been any changes to the rule related to the issue that is flickering? In example rule was removed for a brief moment (for any reason, i.e. plugin removal)?
  2. Have there been any quality profile changes in the project? Especially directly preceding that start of flickering (so around 15th of August 2023 and July 22nd of 2023)?

Thank you in advance

Hi @Lukasz_Jarocki ,

the dates you mention are not the dates when the flickering started. When looking at the “Activity” of the issue it just shows the most recent n status changes, so currently it shows the beginning of February 2024 as earliest change.
It seems like both issues were flickering since they were introduced. The release branch was created on June 22nd, while the issue was created on the master on April 21st by creating the affected file.

Is there a way to see the complete history of an issue?

Regards,
Carsten

Hi,

If you have read access to the database you could find all the issue changes using this query
select * from issue_changes where issue_key = [issue_key] where [issue_key] can be found in the URL (look for URL param called open).

I don’t think we limit number of issue changes shown in the GUI on 9.9.x version so it is interesting what you are reporting.

You also mentioned:

we as well trigger several (6) analyses in a row, as we are working with a monorepo including several projects.

Do you pass the same analysis parameters to each? I understand that the only things that changes between these analyses is a branch name, right?

Hi @sheilemann

please read the findings on this ticket to resolve your problem.

In short: from the information that you provided it seems that you might be using the same project key for two different analyses. This will not result in any error, however you will experience issue flickering.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.