SonarQube 5.4: rules which were removed from a plugin still have dangling data in database causing analyses to fail on the server side

[Francis Galiegue]

Hello,

In this scenario, I have removed some rules from the plugin and end up getting this stack trace:

----

java.lang.IllegalArgumentException: Constant/issue functions must only have a non empty offset
	at org.sonar.api.internal.google.common.base.Preconditions.checkArgument(Preconditions.java:125) ~[sonar-plugin-api-5.4.jar:na]
	at org.sonar.api.server.debt.internal.DefaultDebtRemediationFunction.validate(DefaultDebtRemediationFunction.java:87) ~[sonar-plugin-api-5.4.jar:na]
	at org.sonar.api.server.debt.internal.DefaultDebtRemediationFunction.<init>(DefaultDebtRemediationFunction.java:44) ~[sonar-plugin-api-5.4.jar:na]
	at org.sonar.server.computation.issue.RuleImpl.effectiveRemediationFunction(RuleImpl.java:128) ~[sonar-server-5.4.jar:na]
	at org.sonar.server.computation.issue.RuleImpl.<init>(RuleImpl.java:53) ~[sonar-server-5.4.jar:na]
	at org.sonar.server.computation.issue.RuleRepositoryImpl.loadRulesFromDb(RuleRepositoryImpl.java:102) ~[sonar-server-5.4.jar:na]
	at org.sonar.server.computation.issue.RuleRepositoryImpl.ensureInitialized(RuleRepositoryImpl.java:91) ~[sonar-server-5.4.jar:na]
	at org.sonar.server.computation.issue.RuleRepositoryImpl.findByKey(RuleRepositoryImpl.java:62) ~[sonar-server-5.4.jar:na]
	at org.sonar.server.computation.step.LoadQualityProfilesStep$IsValid.apply(LoadQualityProfilesStep.java:70) ~[sonar-server-5.4.jar:na]
	at org.sonar.server.computation.step.LoadQualityProfilesStep$IsValid.apply(LoadQualityProfilesStep.java:67) ~[sonar-server-5.4.jar:na]
	at com.google.common.collect.Iterators$7.computeNext(Iterators.java:647) ~[guava-17.0.jar:na]
	at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) ~[guava-17.0.jar:na]
	at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) ~[guava-17.0.jar:na]
	at com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:268) ~[guava-17.0.jar:na]
	at com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:226) ~[guava-17.0.jar:na]
	at com.google.common.collect.FluentIterable.toList(FluentIterable.java:334) ~[guava-17.0.jar:na]
	at org.sonar.server.computation.step.LoadQualityProfilesStep.execute(LoadQualityProfilesStep.java:63) ~[sonar-server-5.4.jar:na]
	at org.sonar.server.computation.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:39) ~[sonar-server-5.4.jar:na]
	at org.sonar.server.computation.taskprocessor.report.ReportTaskProcessor.process(ReportTaskProcessor.java:72) ~[sonar-server-5.4.jar:na]
	at org.sonar.server.computation.taskprocessor.CeWorkerCallableImpl.executeTask(CeWorkerCallableImpl.java:80) [sonar-server-5.4.jar:na]
	at org.sonar.server.computation.taskprocessor.CeWorkerCallableImpl.call(CeWorkerCallableImpl.java:55) [sonar-server-5.4.jar:na]
	at org.sonar.server.computation.taskprocessor.CeWorkerCallableImpl.call(CeWorkerCallableImpl.java:34) [sonar-server-5.4.jar:na]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_74]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_74]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_74]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_74]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_74]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_74]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_74]
	at java.lang.Thread.run(Thread.java:745) [na:1.8.0_74]
2016.03.22 19:50:46 ERROR [o.s.s.c.t.CeWorkerCallableImpl] Executed task | project=CacheGitHubCI | id=AVOfqKE2SZKLodz0mP4y | time=102958ms

----

By looking this up on duckduckgo, I found this post on StackOverflow:

http://stackoverflow.com/q/33846181

But the problem I face is a little different.

I debugged SonarQube and found that in fact, this error was triggered by a rule which did not exist anymore... But the database retained some information from these old rules which triggered this failure.

I had to delete from rules in the database directly in order to fix the problem...

Is this a known problem?

[Francis Galiegue]

Hm. Now that I think of it, my plugin still uses a RulesFinder... Could that be related?