Issues only shown on overview tab and as a count on the code tab, but not on issues tab

  • We are using sonarqube 9.5 (build 56709) developer edition, but have seen this problem on earlier versions.
  • I want to drill down to the details of the issues that sonarqube has found

With almost all of our projects we have branches that when viewed in the sonarqube UI, show counts greater than zero for bugs, vulnerabilities or code smells on the overview tab of that project (either under ‘new code’ or ‘overall code’), but that don’t show any issues when you click through on one of these counts to the ‘issues’ tab. Even clearing all filters will not show any, and the ‘No issues. Hooray!’ is shown instead.

Something similar happens when I go through the ‘code’ tab. As long as I am in the table view of my files and directories there are counts greater than zero, but as soon as I hit a specific file that according to these counts does have issues, they don’t show up in the source code view.

Does anyone recognize this or better still knows what is going on and how to fix this ?

Thanks in advance,

Hi Marcel,

Welcome to the community!

This sounds like a corrupt Elasticsearch index. Can you try:

  • stop the server
  • delete $SONARQUBE-HOME/data/es7
  • start the server

And see if the problem persists once the indices are fully rebuilt?


Ann, thanks for the reply, but the restart and deleting the es7 folder did not solve it

Hi @ericrichter,

Welcome to the community!

I guess you and Marcel work together?


Hi Ann

Yes we do, but today he’s got a day off.

As Eric said, unfortunately clearing the elastic search index didn’t solve our problem. Do you have other ideas what may be causing this ?

Regards, Marcel

Hi guys,

Could one of you do one of the click-thrus where the issues a missing & check the developer tools to see if there are errors in either the console or the network tab?


The only error is a 404 on a call to the path ‘/sonar/api/alm_settings/get_binding?project=xxx’ where xxx is the projectkey. The response contains {“errors”:[{“msg”:“Project \u0027xxx\u0027 is not bound to any ALM”}]} with again xxx instead of the project key.

Calls to the path ‘/sonar/api/issues/search’ return json with an empty array as value for the ‘issues’ in the error case and an array with the same number of records as the issue count otherwise.


Thanks for checking. I’m officially out of my depth and have flagged this for more expert attention.


OK, thanks for your help so far.

Are the issue counts correct right after an analysis is performed?
A few screenshots could be helpful.

Yes, performing a new analysis will fix the problem. However, I haven’t been able to figure out a pattern for after how much time the problem starts to show up.
By the way, the issue counts are always correct as far as I can tell: it is in the ‘issues’ and ‘code’ tabs that issues are not shown. The following screenshots should illustrate this.

Recent analysis with issues and what is shown after I click through to the 4 bugs (so this is working as expected):

Older analysis where after a click on the 4 issues they are not shown:

Something similar occurs with the ‘code’ view. For brevity I only show the case when the problem occurs. The class has a code smell (Thread.sleep() ), but it is not shown when I click through to the code.


Hi Marcel,
Since it looks like it’s a small project, maybe you could run a DB query to see what issues are actually stored, so that we can figure out if the problem is related to indexing.

If you can, when experiencing the problem please run:

AND p.KEE = '{project key}'
AND pb.KEE = '{branch or PR key}'

Note that it will return all issues in the branch, so it’s only effective for projects with a very low number of issues, like the one you showed in the screenshot.

issue.txt (41.7 KB)
Here’s the output of the query

Hi Duarte

Have you had a chance to look at our update ?

Regards, Marcel

Hi, the output looks good, so it looks like there’s something wrong with the elastic search index.
Did you check the logs of all 3 processes (es.log, web.log, ce.log) to see if there are any errors? Specially in the es.log.
Also was the problem at least temporarily fixed when you follow Ann’s procedure of removing data/es7 and waiting a bit after restart for SQ to reindex all the data?