Security Hotspots of status REOPENED fail background tasks after v2025.5 upgrade

SonarQube Server / Community Build
, , , ,
1

Hi everyone,

Today I upgraded our self-hosted SonarQube Server Enterprise Edition from v2025.1 (102418) to v2025.5 (113872). I am using the official Helm Chart. After the upgrade I triggered a scan of the main branch of our largest project. That scan was successful but the initiated server-side background task failed with the following stacktrace (collapsed for better readability):

Background task stacktrace 
org.sonar.ce.task.projectanalysis.component.VisitException: Visit of Component {key=<redacted>:<redacted>,type=FILE} failed
  at org.sonar.ce.task.projectanalysis.component.VisitException.rethrowOrWrap(VisitException.java:44)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visit(VisitorsCrawler.java:71)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitChildren(VisitorsCrawler.java:107)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitImpl(VisitorsCrawler.java:94)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visit(VisitorsCrawler.java:69)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitChildren(VisitorsCrawler.java:107)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitImpl(VisitorsCrawler.java:94)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visit(VisitorsCrawler.java:69)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitChildren(VisitorsCrawler.java:107)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitImpl(VisitorsCrawler.java:94)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visit(VisitorsCrawler.java:69)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitChildren(VisitorsCrawler.java:107)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitImpl(VisitorsCrawler.java:94)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visit(VisitorsCrawler.java:69)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitChildren(VisitorsCrawler.java:107)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitImpl(VisitorsCrawler.java:94)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visit(VisitorsCrawler.java:69)
  at org.sonar.ce.task.projectanalysis.step.ExecuteVisitorsStep.execute(ExecuteVisitorsStep.java:51)
  at org.sonar.ce.task.step.ComputationStepExecutor.executeStep(ComputationStepExecutor.java:90)
  at org.sonar.ce.task.step.ComputationStepExecutor.executeSteps(ComputationStepExecutor.java:81)
  at org.sonar.ce.task.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:68)
  at org.sonar.ce.task.projectanalysis.taskprocessor.ReportTaskProcessor.process(ReportTaskProcessor.java:75)
  at org.sonar.ce.taskprocessor.CeWorkerImpl$ExecuteTask.executeTask(CeWorkerImpl.java:212)
  at org.sonar.ce.taskprocessor.CeWorkerImpl$ExecuteTask.run(CeWorkerImpl.java:194)
  at org.sonar.ce.taskprocessor.CeWorkerImpl.findAndProcessTask(CeWorkerImpl.java:160)
  at org.sonar.ce.taskprocessor.CeWorkerImpl$TrackRunningState.get(CeWorkerImpl.java:135)
  at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:87)
  at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:53)
  at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:128)
  at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:74)
  at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:80)
  at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
  at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
  at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
  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)
Caused by: java.lang.IllegalStateException: Fail to process issues of component '<redacted>:<redacted>'
  at org.sonar.ce.task.projectanalysis.issue.IntegrateIssuesVisitor.visitAny(IntegrateIssuesVisitor.java:107)
  at org.sonar.ce.task.projectanalysis.component.TypeAwareVisitorWrapper.visitAny(TypeAwareVisitorWrapper.java:77)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitNode(VisitorsCrawler.java:114)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitImpl(VisitorsCrawler.java:97)
  at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visit(VisitorsCrawler.java:69)
  ... 35 common frames omitted
Caused by: java.lang.IllegalStateException: Unknown status: REOPENED [issue=<redacted>]
  at com.google.common.base.Preconditions.checkState(Preconditions.java:834)
  at org.sonar.server.issue.workflow.securityhotspot.SecurityHotspotWorkflow.stateOf(SecurityHotspotWorkflow.java:84)
  at org.sonar.server.issue.workflow.securityhotspot.SecurityHotspotWorkflow.doAutomaticTransition(SecurityHotspotWorkflow.java:73)
  at org.sonar.server.issue.workflow.IssueWorkflow.doAutomaticTransition(IssueWorkflow.java:69)
  at org.sonar.ce.task.projectanalysis.issue.IssueLifecycle.doAutomaticTransition(IssueLifecycle.java:229)
  at org.sonar.ce.task.projectanalysis.issue.IntegrateIssuesVisitor.processIssue(IntegrateIssuesVisitor.java:210)
  at org.sonar.ce.task.projectanalysis.issue.IntegrateIssuesVisitor.lambda$processIssues$1(IntegrateIssuesVisitor.java:165)
  at java.base/java.lang.Iterable.forEach(Unknown Source)
  at org.sonar.ce.task.projectanalysis.issue.IntegrateIssuesVisitor.processIssues(IntegrateIssuesVisitor.java:165)
  at org.sonar.ce.task.projectanalysis.issue.IntegrateIssuesVisitor.visitAny(IntegrateIssuesVisitor.java:101)
  ... 39 common frames omitted

I am not sure if this is important to know: prior to upgrading I cleared the PVC containing “logs”, “certs”, “data”, “extensions” and “temp” folders. In an earlier upgrade (years ago) this was recommended and I kept this habit.

Because that error failed our CI pipeline (it waits for success response), I rolled back to v2025.1 by restoring the DB backup and restoring a copy of the PVC which I cleared for the upgrade.

After successfully restoring the backup our CI pipeline succeeds again. So I inspected the issues table and searched for the issue id from the stacktrace. I found that this issue has status REOPENED. Out of curiosity I checked for other issues of same type and status (WHERE status = 'REOPENED' and issue_type = 4) and found about 50 others in different projects.

Re-reviewing the changelog between both versions I found following 2 changes related to REOPENED:

My questions now are:

  • Do I have to upgrade to an intermediate version first for a correct migration?
  • Have I done something wrong while upgrading?
  • How do I resolve this issue so that I can upgrade to the newest version?

Many thanks in advance for your help.

Best regards,
Steven

2

Hi Steven,

Thanks for your thorough investigation & report!

I suppose your upgrade logs looked clean?

You shouldn’t have to

I wouldn’t think so.

I’m going to flag this for the team to figure out!

 
Ann

5

Hi Ann. Thanks for your response. Glad I did nothing wrong with the upgrade. And yes, the upgrade logs did not indicate errors. :slight_smile:

Do you have a link or issue tracker ID where I can follow “figuring-out” progress?

If you need anything from me to help investigating, please let me know.

Best regards,
Steven

6

Hi Steven,

Unfortunately, I don’t have a link for you. Hopefully someone from the team will be along soon.

 
Ann

1 Like
8

Hi @justus_bunsi!

Thank you for reporting this issue and for your investigation!

I created the ticket SONAR-26786 to keep track of this issue.

Could you answer the following questions:

  1. Do you have GitHub integration enabled? Specifically, are you using GitHub Code Scanning with SonarQube?
  2. If yes, did the affected security hotspots originate from GitHub Code Scanning alerts?

Thank you in advance!

Victor

9

Hi @victor.schneuwly, thanks for creating the tracking issue. We are not using GitHub integration as we currently use Gitea. Our scanner runs within Jenkins jobs.

EDIT: I read your comment in the issue. Maybe the hotspot was reopened after a PR was merged in which this issue got introduced and fixed. We use Pull Request scans so could it be an issue with transferring hotspots after merge or PR cleanup?

10

Hi @justus_bunsi!

I hope you had a nice holiday period.

Thank you for the additional information! I will take this into account as I continue the investigation.

Best regards,

Victor

1 Like