We have had sonarqube running successfully in AWS ECS Fargate, with RDS Postgresql for over 2 weeks on version 2025.1 LTA. Today we updated to the latest version of Sonarqube (2025.2). After we pushed the updated version to ECR, updated our service task and went to our URL\setup, we went through the process of updating the database and received the message “Database is up-to-date” screen, Sonarqube enters a continuous restart loop. The error in the task logs show:
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@77a7cf58-org.sonar.server.qualityprofile.RegisterQualityProfiles’: Duplicate key jsp/Sonar way (attempted merging values org.sonar.db.qualityprofile.RulesProfileDto@11d7b384 and org.sonar.db.qualityprofile.RulesProfileDto@7e6c11a7)
I have restored the database multiple times from when it was last known to be working. I’ve checked the tables in the database and there is no table labeled “quality.profiles”. I also checked our production server running on RHEL 8, and that database also has no table named “quality.profiles”. I checked the schema, and we only have Public as our schema.
I reverted back to version 2025.1 and restored the database again, and we are now able to launch Sonarqube without issue. There seems to be a bug with 2025.2 when upgrading postgresql database with Sonarqube hosted in Fargate.
So, it seems your DB was corrupted at some point. Having duplicate built-in Sonar way profiles for every language is very suspicious. It was indeed possible – although unlikely – to forcefully create 2 profiles with the same name, for the same language (this was checked and rejected at the API level, but not at the schema level). But having both marked as built-in is impossible, as you cannot create a built-in profile via our APIs; only a profile registered by a plugin can be flagged as built-in.
How long have you been seeing these duplicate profiles? Was there a backup restoration at some point?
We can guide you to drop the offending lines from the DB, and that should fix your immediate issue. That being said, if this is indeed triggered by a past backup restore that went wrong, there may be other duplicates in other tables, which will be hard to spot and can cause issues later on.
In order to clean up the DB, it would help to know if the UUIDs are unique, or are now duplicated. Can you run the following query:
SELECT COUNT(rp.uuid), rp.uuid, rp.language
FROM org_qprofiles oqp
JOIN rules_profiles rp ON oqp.rules_profile_uuid = rp.uuid
WHERE rp.name = 'Sonar way'
AND rp.is_built_in = true
GROUP BY rp.uuid, rp.language
This is to see if the UUIDs are unique. If all counts are 1, it means they share the UUID and cleaning up may be trickier.
I was able to restore our database from our prod server and upgrade to 2025.2 without issue. Not sure what caused the duplicates, but this issue is now resolved.
Looks like the issue was caused by the fact that we did not stop the ECS task prior to updating to the newest version of Sonarqube, which forced it to try and create duplicates of the Sonar Way Quality Profiles.
