Upgrade from 25.5 to 25.6 fails with duplicate key external_roslyn:CS8603

SonarQube Server / Community Build
1
  • how is SonarQube deployed: Docker
  • what are you trying to achieve: Upgrade from 25.5.0.107428 to 25.6.0.109173
  • what have you tried so far to achieve this: After starting the required database update, the following Exception encountered:
sonarqube  | 2025.07.18 11:48:11 WARN  web[][o.s.c.a.AnnotationConfigApplicationContext] Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jdk.internal.loader.ClassLoaders$AppClassLoader@49872d67-org.sonar.server.rule.registration.RulesRegistrant': Duplicate key external_roslyn:CS8603 (attempted merging values org.sonar.db.rule.RuleDto@a8f5c7fd and org.sonar.db.rule.RuleDto@5de1940b)
sonarqube  | 2025.07.18 11:48:11 ERROR web[][o.s.s.p.Platform] Background initialization failed. Stopping SonarQube
sonarqube  | org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jdk.internal.loader.ClassLoaders$AppClassLoader@49872d67-org.sonar.server.rule.registration.RulesRegistrant': Duplicate key external_roslyn:CS8603 (attempted merging values org.sonar.db.rule.RuleDto@a8f5c7fd and org.sonar.db.rule.RuleDto@5de1940b)

No plugins installed, Postgresql is dockered 17.5-alpine

Any help is appreciated

2

Hi,

Welcome to the community!

I don’t think this is going to help. But only the latest version of Community Build is supported. So can you please point 25.7 at your DB and verify you get the same error?

 
Thx,
Ann

3

Same problem: Duplicate key external_roslyn:CS8603 during database migration

1 Like
4

Hi,

Thanks for trying the upgrade. I’m going to flag this for more expert eyes.

 
Ann

1 Like
7

Hello @derMatze,

I think I will need a bigger portion of the logs to better understand what is going on here.
This case reminds me a very similar one we had with a Data Center edition where multiple nodes of the cluster were trying to register the rules at the same time.

In your case, can you confirm that the database being used by the instance on 25.6 is not shared at all with the instance running on 25.5?

After the error you paster here, do you have something like this in the logs:

### Error committing transaction.  Cause: org.apache.ibatis.executor.BatchExecutorException: org.sonar.db.rule.RuleMapper.insertRuleDescriptionSection (batch index #3) failed. 2 prior sub executor(s) completed successfully, but will be rolled back. Cause: java.sql.BatchUpdateException: Batch entry 0 insert into rule_desc_sections (
      uuid,
      rule_uuid,
      kee,
      content,
      context_key,
      context_display_name
    )
    values (
      ('AYd2Ci2JI7EZ4cTavtDM'),
      ('AXYlqPUl3JNJ_j8XDKU-'),
      ('default'),
      ('See description of Pylint rule <code>C0413</code> at the <a href="https://pylint.pycqa.org/en/latest/technical_reference/features.html">Pylint website</a>.'),
      (NULL),
      (NULL)
    ) was aborted: ERROR: duplicate key value violates unique constraint "pk_rule_desc_sections"

Please send the extended version of your logs so we can have a better picture of the problem.

Regards,
Matteo

1 Like
8

Please find the log attached
sonarqube.log (39.4 KB)

The database is not shared. I stopped the sonarqube container, increase the image version in docker compose file, and start up the container again

9

Have you had a chance to check out lofgile yet?

10

Hello @derMatze I am just back from holidays. and I am going to check the logs this week.
I know it is a bit a of a weird request, but, have you checked if you get the same behavior also updating to 25.7 or 25.8 that got released in the meantime?

11

Thanks! Yes, I also tried upgrading directly to the current version but the error remains. I think it´s a kind of migration which has to be done in any version > 25.5

12

Is it always the same rule registration failing also when moving to the other versions?

external_roslyn:CS8603

If the migration is running on a copy of the original data I would suggest to delete the rule from the Database and run again the migration. Just to make sure that something is not corrupted with that specific entry.

If after doing that the issue still materializes on another rule I am a bit out of ideas.
As already mentioned, I saw this problem in the past in a datacenter edition, but the customer never told us how the issue was fixed.

13

Thanks for the tip! I removed all duplicates (~30 in total) and the update to the latest version worked.

1 Like
14

Thank you very much @derMatze fro letting us know that you managed to fix the problem.
I don’t have a real explanation about the registration of the rules at upgrade time was resulting in duplicates, but we will totally keep this case in mind if this problem arises again.

1 Like