Project Data Reload Background issues after upgrading to Developer 10.8

Hi All,

I have recently upgraded my SonarQube instance from Community version 10.6 to Developer version 10.8 (Previously i upgraded from Community version 10.3 → Community version 10.6). After the upgrade i started getting numerous background task failures. The “Project Data Reload” task is failing with these errors:

Error Details
org.apache.ibatis.executor.result.ResultMapException: Error attempting to get column 'rdi_severity' from result set.  Cause: java.lang.IllegalArgumentException: No enum constant org.sonar.api.issue.impact.Severity.BLOCKER
	at org.apache.ibatis.type.BaseTypeHandler.getResult(BaseTypeHandler.java:88)
	at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.createRowKeyForMappedProperties(DefaultResultSetHandler.java:1181)
	at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.createRowKey(DefaultResultSetHandler.java:1142)
	at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.applyNestedResultMappings(DefaultResultSetHandler.java:1065)
	at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.getRowValue(DefaultResultSetHandler.java:449)
	at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.handleRowValuesForNestedResultMap(DefaultResultSetHandler.java:1025)
	at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.handleRowValues(DefaultResultSetHandler.java:335)
	at org.apache.ibatis.cursor.defaults.DefaultCursor.fetchNextObjectFromDatabase(DefaultCursor.java:141)
	at org.apache.ibatis.cursor.defaults.DefaultCursor.fetchNextUsingRowBound(DefaultCursor.java:125)
	at org.apache.ibatis.cursor.defaults.DefaultCursor$CursorIterator.hasNext(DefaultCursor.java:197)
	at org.sonar.server.issue.index.IssueIteratorForSingleChunk.hasNext(IssueIteratorForSingleChunk.java:78)
	at org.sonar.server.issue.index.IssueIndexer.doIndex(IssueIndexer.java:321)
	at org.sonar.server.issue.index.IssueIndexer.indexOnAnalysis(IssueIndexer.java:127)
	at org.sonar.ce.task.projectanalysis.taskprocessor.IndexIssuesStep.lambda$execute$1(IndexIssuesStep.java:52)
	at java.base/java.util.Optional.ifPresent(Optional.java:178)
	at org.sonar.ce.task.projectanalysis.taskprocessor.IndexIssuesStep.execute(IndexIssuesStep.java:48)
	at org.sonar.ce.task.step.ComputationStepExecutor.executeStep(ComputationStepExecutor.java:79)
	at org.sonar.ce.task.step.ComputationStepExecutor.executeSteps(ComputationStepExecutor.java:70)
	at org.sonar.ce.task.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:57)
	at org.sonar.ce.task.projectanalysis.taskprocessor.IssueSyncTaskProcessor.process(IssueSyncTaskProcessor.java:60)
	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:131)
	at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:76)
	at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:82)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.IllegalArgumentException: No enum constant org.sonar.api.issue.impact.Severity.BLOCKER
	at java.base/java.lang.Enum.valueOf(Enum.java:273)
	at org.apache.ibatis.type.EnumTypeHandler.getNullableResult(EnumTypeHandler.java:49)
	at org.apache.ibatis.type.EnumTypeHandler.getNullableResult(EnumTypeHandler.java:26)
	at org.apache.ibatis.type.BaseTypeHandler.getResult(BaseTypeHandler.java:86)
	... 34 more

I also pulled from the Console Error Logs this:

2025.01.08 17:58:52 INFO  ce[][o.s.c.c.ComputeEngineContainerImpl] Running Developer edition
2025.01.08 17:58:53 INFO  ce[][o.s.ce.app.CeServer] Compute Engine is started
2025.01.08 18:04:21 INFO  ce[][o.s.c.t.CeWorkerImpl] Execute task | project=APIv6-UserApi | type=REPORT | id=00b42357-31ce-43ed-a018-ae9827d210c6 | submitter=saurabh65170
2025.01.08 18:04:22 INFO  ce[00b42357-31ce-43ed-a018-ae9827d210c6][o.s.s.e.EsClientProvider] Connected to local Elasticsearch: [http://127.0.0.1:9002]
2025.01.08 18:04:22 INFO  ce[00b42357-31ce-43ed-a018-ae9827d210c6][o.s.c.t.s.ComputationStepExecutor] Extract report | status=FAILED | time=3ms
2025.01.08 18:04:22 ERROR ce[00b42357-31ce-43ed-a018-ae9827d210c6][o.s.c.t.s.ComputationStepExecutor] Execution of listener failed
java.lang.IllegalStateException: Directory has not been set yet
	at org.sonar.ce.task.projectanalysis.batch.BatchReportDirectoryHolderImpl.getDirectory(BatchReportDirectoryHolderImpl.java:37)
	at org.sonar.ce.task.projectanalysis.batch.BatchReportReaderImpl.ensureInitialized(BatchReportReaderImpl.java:54)
	at org.sonar.ce.task.projectanalysis.batch.BatchReportReaderImpl.readContextProperties(BatchReportReaderImpl.java:209)
	at org.sonar.ce.task.projectanalysis.api.posttask.PostProjectAnalysisTasksExecutor.createProjectAnalysis(PostProjectAnalysisTasksExecutor.java:155)
	at org.sonar.ce.task.projectanalysis.api.posttask.PostProjectAnalysisTasksExecutor.finished(PostProjectAnalysisTasksExecutor.java:90)
	at org.sonar.ce.task.step.ComputationStepExecutor.executeListener(ComputationStepExecutor.java:89)
	at org.sonar.ce.task.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:61)
	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:131)
	at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:76)
	at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:82)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)

The SonarQube is installed via zip folder on a windows machine. Has anyone ran into this issue before?

Hey @giturr14!

Can you:

  • Ensure that only one SonarQube instance is connected to your database. Checking your active database connections (to the DB hosting SonarQube) is a great way to ensure this.
  • Force an elasticsearch reindex

And see if the issue persists?

Hi Colin, thanks for the reply! I ran a query on our SonarQube Oracle DB:

SELECT sid, serial#, username, status FROM v$session WHERE status = ‘ACTIVE’;

It looks like there are numerous “Null” connections, one “SonarQube” user connection and one “sys” connection. Does this look normal?

Let’s assume this means that only one SonarQube instance is connected to your database. Have you forced an elasticsearch reindex?