which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
SonarQube 9.9 LTS version, SonarScanner 4.6.2.2472, AzureAD plugin
how is SonarQube deployed: zip, Docker, Helm
Through Helm
what are you trying to achieve
Sonar scanning. Report update failed
Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!
Failed message is:
{“task”:{“id”:“AYdWZ64WkMjeyYjvuSR7”,“type”:“REPORT”,“componentId”:“AWv12uGunZ8iPkPy8Uca”,“componentKey”:“nl.kadaster.ozon:ozon-export-service”,“componentName”:“ozon-export-service”,“componentQualifier”:“TRK”,“status”:“FAILED”,“submittedAt”:“2023-04-06T11:50:48+0000”,“submitterLogin”:“lvbbod-jenkins”,“startedAt”:“2023-04-06T11:50:49+0000”,“executedAt”:“2023-04-06T11:50:52+0000”,“executionTimeMs”:2908,“errorMessage”:“Can not find DTO for assignee uuid topper”,“hasScannerContext”:true,“branch”:“master”,“branchType”:“BRANCH”,“warningCount”:0,“warnings”:}}
In this message the lvbbod-jenkins account is an internal SonarQube account and uuid topper is an on-premise active directory account.
When migrating to Azure AD plugin, all the on-premise accounts were removed from the database. ( because of a conflict with there mail addresses )
When we’ve seen this issue in the past, it’s the result of database entries in the users table being manually purged from the database, which results in inconsistent data.
To try and grasp the scope of the issue, can you run this query against your database?
select p.kee, i.assignee, u2.login, count(i.kee)
from issues i
left outer join users u on i.assignee = u.uuid
join projects p on i.project_uuid = p.uuid
left outer join users u2 on i.assignee = u2.login
where u.uuid is null and i.assignee is not null
group by p.kee, i.assignee, u2.login
order by count(i.kee) desc
This query was designed for Postgres – it may work across other database platforms
First I think it’s important to understand the scope of the issue. How many individual logins are listed? How many issues (the total of the count column)?
What do you mean by “old accounts” – are these accounts that might have been manually manipulated in the database?
The query showed me a total of > 1300 hits. And a few hundred of them with a great count.
The ‘readable’ accounts are all ‘old’ accounts from our on-premise active directory.
We changed the SonarQube implementation from our on-premise environment to our cloud environment ( within Open Shift ) and thereby had to change the authentication process using the Azure AD plugin.
I had to delete the ‘old’ accounts, because they had the same email address as the users from Azure AD.
So they were not able to login through the Azure AD plugin interface anymore.
That’s why I deleted all the ‘old’ accounts from the user table.
It’s really a nightmare to manually edit the database, as opposed to deactivating the users. It results in data inconsistencies that causes errors… like this one. It results in the notifications that users have signed up for, which exists in another table, referencing a user that no longer exists.
I can’t speak to what issues you might face down the road having done this.
And, you can probably circumvent this current issue by:
Backing up the database in case something goes wrong
Executing a query: update issues set assignee = null where assignee = '<assignee no longer existing in users table>'; for each of those users (there’s probably some more clever SQL that exists to derive the list of users from the previous query)
