Sonarqube 8.8 New bug display is empty

Hey @123dev,

Could you execute following query on your database?

select to_timestamp(issue_creation_date/1000), count(kee) 
from issues i
where  i.issue_creation_date > 1619042400000 and i.issue_creation_date < 1619301600000 and i.project_uuid = (select p.uuid from projects p where p.kee = '{YOUR_PROJECT_KEY}') 
group by issue_creation_date;

Hi Jacek,
Here’s the result of the query.

image

Thanks @123dev ,

There is one more thing you could do, to help me analyse that issue, as I still struggle with investigation what’s wrong.

Could you enable TRACE logging in your SQ instance and sent me all file logs it will produce (web, es etc.)?

It would be great that you would enter issues page during that, so that I could check logs during that issue you have.

Cheers,
Jacek

Hi Jacek,
I upgraded to 8.9, enabled Trace as requested and went the problem area which was still reproducible, and captured all the logs.
How can I privately send you all the logs, I suspect it has some sensitive content.

I will be turning off the tracing now due to the performance impact

Thanks

I’ve sent you a private message.

Thank Jacek,
Logs are sent.

@123dev ,

I’ve took a look at the logs and there is only one request to the web for issues.

Further more returned issues have keys: “AXlCG5fcY-tIFhSKZYoA”, “AXlCG5fcY-tIFhSKZYoB”, can you check if they both exist in your DB? (select * from issues i where i.kee in ('AXlCG5fcY-tIFhSKZYoA','AXlCG5fcY-tIFhSKZYoB') if they didn’t appear on UI)

And the date which has appeared in the request was 162025029705/05/2021 - is that correct? Is this what you were requesting? Was the result correct on UI this time or something was wrong?

Hi Jacek,

The query returns two matches

I’m not sure why the date in the request would be wrong, perhaps that is the root issue.
I made the request after I upgraded to 8.9 yesterday, and turned on tracing
I made the request, navigated to the problem, did not observe anything different than what this ticket is about, ie I still couldn’t see the details
Captured the logs.

Thanks

Hi Jacek,
Any luck with this?

Thanks

Hi,
We are still having trouble figuring this out.
How are you binding the volumes with docker?
Could you please drop the es7 folder again and restart SonarQube? To be sure it worked, please send us the logs after restarting since it should show ES reindexing the database.

If the issues still don’t show up in the New Code tab, please send us the following:

  • Screenshot
  • TRACE logs when opening that page
  • WS response

I know you’ve sent us this before, but it wasn’t all at the same time so it’s hard to connect all the data. We noticed that the New Code period has changed between posts, for example.

Hi Duarte,
Thanks for the follow up.

How are you binding the volumes with docker?
In docker compose:

    volumes:
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions
      - sonarqube_logs:/opt/sonarqube/logs

Due to the sensitive nature of the file, I’ll be sending you a DM message on where the logs can be downloaded from.

I’ve done everything you’ve asked for.
Please let me know if all you need is there.

Thanks

Sorry, couldn’t find a way to send you a DM, hence I emailed to Jacek,
Please let me know if you get it, if not, just DM me so that I know where to send.
Thanks

Any update folks?

Thanks for sending the logs.
It looks like the re-indexing is being done at startup.

Could you please try to run the following query and see if the 2 issues are found?

select i.kee as kee, i.rule_uuid as ruleUuid, i.severity as severity, i.manual_severity as manualSeverity, i.message as message, i.line as line, i.locations as locations, i.gap as gap, i.effort as effort, i.status as status, i.resolution as resolution, i.checksum as checksum, i.assignee as assigneeUuid, i.author_login as authorLogin, i.tags as tagsString, i.issue_attributes as issueAttributes, i.issue_creation_date as issueCreationTime, i.issue_update_date as issueUpdateTime, i.issue_close_date as issueCloseTime, i.created_at as createdAt, i.updated_at as updatedAt, r.is_external as "isExternal", r.plugin_rule_key as ruleKey, r.plugin_name as ruleRepo, r.language as language, p.kee as componentKey, i.component_uuid as componentUuid, p.module_uuid as moduleUuid, p.module_uuid_path as moduleUuidPath, p.path as filePath, root.kee as projectKey, i.project_uuid as projectUuid, i.issue_type as type from issues i inner join rules r on r.uuid=i.rule_uuid inner join components p on p.uuid=i.component_uuid inner join components root on root.uuid=i.project_uuid where i.kee in ( 'AXlheCdcd1kawb4PTSAY' , 'AXlheCdcd1kawb4PTSAZ' )

Thanks @dmeneses
That query returns 0 matches.

Successfully run. Total query runtime: 149 msec.
0 rows affected.

Thanks. That’s the query actually used by the webservice so it makes sense that nothing shows up.
Could you please also try this query:
select * from issues i where i.kee in ( 'AXlheCdcd1kawb4PTSAY' , 'AXlheCdcd1kawb4PTSAZ' )

Thanks
Two matches



@123dev Seems like we are getting closer to the root issue, could I ask you to execute additional queries?

//issue rules (issues' rule_uuid)
select * from rules r where r.uuid in ( '7144', '7132' )

//issues project (issues' project_uuid)
select * from components p where p.uuid = 'AWiVCSdKzF5unp-9Lr15';

//issues component (issues' component_uuid)
select * from components c where c.uuid = 'AXAQpirbSF2ZeVaUtZJ_';

Hi Jacek,
Here are the results of the queries



image




image


No matches.

Hope it helps.
Thanks

Thanks, it gave us some clue, though in order to proceed further with investigation, we would need you to send us logs from scanner execution, ideally with DEBUG enabled. Also if you could include compute engine logs (TRACE enabled if possible) from that analysis time.