Additional evidence: this behavior appears isolated to one project. We have four SonarCloud projects in the same organization, but only this project shows today’s Quality Profile Use 'Sonar way' events for JSON and Azure Resource Manager, followed by Quality Gate state changes. Other projects do not show this profile-change activity and their issue status actions still work normally. This suggests a project-specific reprocessing/indexing problem rather than an organization-wide permission or configuration issue.
“The quality profile assigned to this project has changed. You can explore the change in the Activity page.”
The issue has stabilized after re-reviewing the Security Hotspots, however we are still seeing project-specific behavior differences compared to other projects in the same organization. We would appreciate confirmation whether any background reprocessing, profile migration, or hotspot reclassification activity occurred on June 17.
Hey @Mada_B, it seems there might be a few different issues at play here! Let’s go one by one:
1. Security Hotspots were reopened after review
We have seen some users experience this in the past because of an incomplete analysis (for example a shallow checkout or non-clean build) which temporarily closes existing hotspots and then re-creates them in a later full analysis, losing the previous review state. To try to understand if this was the case, could you go to Project > Activity > Measures for the affected branch > check for sudden dips/spikes in Lines of Code, Issues, or Security Hotspots around June 17?
3. Previously fixed issues are being reported again
The same answer I gave for point 1 applies here, could you please do the same check?
4. Issue assignment appears to have been recalculated
I would treat it as the same: issues could have been re-opened by incomplete analysis or missing SCM data (which is related to incorrect issue authorship detection).
5. Issue status actions appear unavailable
6. As project administrators/owners, we are unable to change the status of some Code Smell issues.
7. The “Change” action opens a dialog but contains no available actions and the Apply button remains disabled.
This sounds like a permissions issue. The permission that enables you to change hotspot statuses is “Administer Issues”. Do you have this permission on this project?
I am the owner and administrator of the entire organization, so I have full permissions across all projects.
Even after implementing Sonar’s suggested fixes, pushing the changes, and rerunning the analysis, Sonar continues to report issues that no longer exist.
For example, it still reports trailing whitespace issues even though the whitespace has been removed. The issues remain open and continue to suggest fixes that have already been applied. We are seeing the same behavior with other findings as well, such as variable capitalization issues that have already been corrected.
Another example is the rule suggesting changing the cmdlet name from Write-host to Write-Host. In this case, we may choose to keep the current implementation because it is intentional and has already been validated in our pipeline. However, we are unable to change the issue status to Accepted. The issue remains Open, the status is greyed out, and neither the bulk change operation nor the individual issue view provides any available status transitions.
This does not appear to be a permissions issue, as we have always been able to mark issues as Accepted in this project up until yesterday. The behavior started at the same time we received the notification indicating that the Quality Profile/Quality Gate had changed.
This behavior is isolated to a specific project. Other projects within the same organization continue to behave normally and still allow issue status changes such as Accept, False Positive, Confirm, and Fixed.
As for the incomplete analysis suggestion, that is not the case.
The analysis completed successfully and there were no errors or warnings indicating an incomplete scan. No relevant code changes were made during this period.
What did happen is that we received a notification from Sonar indicating that the Quality Profile/Quality Gate had been updated. We are using the built-in Sonar way profiles.
When the Security Hotspots first appeared, I reviewed all of them and marked them as Safe. I then reran the analysis and the Quality Gate passed successfully.
Approximately 10 minutes later, without any manual analysis trigger, code changes, or new commits, the same hotspots were reopened and the Quality Gate failed again. This happened twice on the same day.
We have verified through a clean Azure DevOps pipeline run that files previously removed from the repository are no longer present in the checkout prior to SonarCloud analysis.
The pipeline uses a clean checkout with full Git history, and a validation step confirms that the removed files are not present in the workspace before analysis begins. The generated list of files expected to be analyzed also does not include the removed files.
Despite this, SonarCloud continues to display issues associated with files that no longer exist in the repository.
In addition to this behavior, we have observed other project-specific inconsistencies, including issue status changes not being reflected as expected and previously resolved items remaining visible after successful analyses.
Has anyone encountered similar behavior, and is there a known way to force SonarCloud to refresh or rebuild project indexing/issue data when removed files continue to appear in the UI?
Additional validation:
The removed files do not appear under the project’s Code view, so SonarCloud appears to know they are no longer part of the current analyzed codebase.
However, open issues for those same removed files are still visible under the Issues view on the main branch.
So the inconsistency seems to be between the current code inventory and the issue state/index, rather than the scanner still analyzing the removed files.
According to Sonar issue lifecycle behavior, issues should be closed as Fixed when the file is no longer available, but in our case the file is absent from Code and from the CI workspace while the related issues remain Open on the main branch.
Hey @Mada_B, thanks for the thorough explanation and the screenshot. Indeed what you’re seeing looks like quite unusual, the screenshots show some UI inconsistencies. Could you please share the project key where you’re experiencing this?
Just one tiny comment:
I am the owner and administrator of the entire organization, so I have full permissions across all projects.
I wanted to clarify that you could be an org admin and not necessarily have administer issues or administer hotspots permission on a given project. At this point I don’t believe that your problem is caused by a lack of permissions, but just wanted to clarify that.
