Sonarqube 8.8 New bug display is empty

123dev · May 21, 2021, 5:44pm

Hi Jacek,

Just so I have it right, you want any scanner execution log or a specific one?
And what exactly is computer engine logs, the sonarqube server logs with SONAR_LOG_LEVEL=TRACE
?

dmeneses · May 21, 2021, 6:27pm

The logs of the scanner (with debug enabled) when analyzing that specific branch, resulting in 2 issues that aren’t displayed.
The compute engine logs are the server logs, specifically the sonarqube_ce file that you sent before. We are interested in also seeing what happens there when the analysis is processed after being executed by the scanner.

123dev · May 21, 2021, 8:09pm

OK, email sent to Jacek.

Thanks

123dev · May 27, 2021, 12:57pm

Any update folks?

Thanks

jacek.poreda · May 28, 2021, 3:59pm

Sorry for delay, we still have a problem to identify a cause of that unexpected behaviour you are encountering.

Could I ask you to execute this query:
select * from components c where c.kee = 'API:API.Main/Views/OAuth/Authorize.cshtml' ?

123dev · May 29, 2021, 12:23pm

Hi Jacek,

No data output

123dev · June 2, 2021, 11:38am

Hi Folks,
Any update?

Thanks

123dev · June 7, 2021, 12:07pm

@jacek.poreda @dmeneses
Any update?

Thanks

jacek.poreda · June 9, 2021, 3:19pm

Hey @123dev,

Sorry for delaying response, we were kinda able to reproduce your issue artificially, here is the bug ticket you can track: SONAR-14956

As a temporary fix - I recommend you to execute this two queries to close issues which are causing problems (please make a backup of DB before doing so) and then reindex Elasticsearch as you did previously:

update issues set status='CLOSED' where kee = 'AXlheCdcd1kawb4PTSAY';
update issues set status='CLOSED' where kee = 'AXlheCdcd1kawb4PTSAZ'

Let me know if that helped.

123dev · June 9, 2021, 4:09pm

Thanks @jacek.poreda
I tried your suggested temporary fix

dropped ES and started again,
sadly I’m still seeing the same issue

Thanks

jacek.poreda · June 9, 2021, 4:59pm

Could you double check if the issues has been updated correctly?

select kee, status from issues where kee in ('AXlheCdcd1kawb4PTSAY' , 'AXlheCdcd1kawb4PTSAZ');

123dev · June 9, 2021, 5:07pm

Thanks

jacek.poreda · June 10, 2021, 7:07am

Hmm, there may be more than this two issues without components.

Could you also execute this query:

select count(*) from issues i left join components c on i.component_uuid  = c. uuid where c.uuid  is null;

This query will allow to see how many issues without attached component you have in your database.

123dev · June 10, 2021, 12:07pm

Sure

Thanks

123dev · June 14, 2021, 12:47pm

Folks,
Any update? any resolution in sight? we really need to get to the bottom of this.
The product usability is seriously handicapped.

Thanks

123dev · June 17, 2021, 12:49pm

@jacek.poreda and @dmeneses
^^^

123dev · June 29, 2021, 12:03pm

@jacek.poreda and @dmeneses
Is this is lost cause after providing all the details you requested?
Should we give up on Sonarqube?

jacek.poreda · July 1, 2021, 1:10pm

Hey @123dev ,

Sorry for not replying for quite some time.

With all the data results you have provided, I’m a bit confused and it is not clear to me how this state could be achieved when operating SQ.

In the beginning it seemed like there are no components associated with issues, but count query with a left join did not return any rows, so we have reached a dead end. Additionally as I cannot find any workaround for now - I recommend to observe a bug ticket I’ve created, it will be tackled at some point.

Best,
Jacek

daniel-huss · July 22, 2021, 2:18pm

Hi everyone,

We’re experiencing the same issue. Do you happen to be using Postgres on Ubuntu? There was a recent glibc update which caused index corruption. That would explains a lot of anomalies, including this one. The poor devs are never going to find an issue in the code if this is the root cause

We were able to solve the issue by running the following DB query: reindex database sonar;
After that, the ES indices had to be rebuilt.

Of course, the index corruption might’ve affected database migrations and previous operation, so stuff could still be broken. We deleted all issues whose foreign key references were invalid (there are no DB constraints for some reason).

I think this query will find broken references, but no guarantees:

select
i.kee as kee
from
issues i
left join rules r on
r.uuid = i.rule_uuid
left join components c on
c.uuid = i.component_uuid
left join components root on
root.uuid = i.project_uuid
where
(i.rule_uuid is not null and r.uuid is null) or
(i.component_uuid is not null and c.uuid is null) or
(i.project_uuid is not null and root.uuid is null)

123dev · October 18, 2021, 5:26pm

Thanks for chiming in,

Docker host is Ubuntu 20.04, however we’re running the office docker containers which if I’m not mistaken are Ubuntu 18.04 based

Unfortunately this gave us the following error.

ERROR:  could not create unique index "live_measures_component"
DETAIL:  Key (component_uuid, metric_uuid)=(AWiWU9KHCT7Y-wQaGA5_, 141) is duplicated.
SQL state: 23505