Filter by file (fileUuids) not showing a valid uuid and not finding any results

  • Sonar Version:

When I’m trying to find issues in a particular file I open up the FILE section and select a given file:

  • Select main.c and I can see the url directs to ?fileUuids=AXizT514........&id=project&results=false

It seems that some files don’t have a valid uuid built. I’m not 100% positive, but it looks like any file that’s not in the root of the project don’t filter properly:

  • Select src/submain.c and I see the url directs to ?f=fileUuids=project%3Asrc%2Fsubmain.c&id=project&results=false

Page shows “We couldn’t find any results matching selected criteria”. But I know there are issues, because I can get to issues in this page from the global issues list without filtering.

When I click the link from the global issues list, the fileUuid does look to be generated properly, so I’m guessing that this is a js issue when the file contains / characters.


It’s not meant to work this way; the uuids are not for public consumption. However, you should be able to navigate to everything via normal use of the interface.


I’m not sure what you mean by “not meant to work this way”. I’m not manually navigating to the uuids, I’m pointing out that they’re not working.

I’m clicking on a file filter : src/submain.c and seeing that the url doesn’t look correct and isn’t working.


Could you share some screenshots of what you’re clicking on and what you’re getting in response?


Clicking on api/documenttypes.c redirected the url to: https://...../project/issues?fileUuids=myProject%3Aapi%2Fdocumenttypes.c&id=myProject&resolved=false

Clicking on a file not in a subdirectory changes the url to: project/issues?fileUuids=AXIzT5IxkwDq6jvlKvef&id=myProject&resolved=false


Your first screenshot shows the selection of a file without any open issues. That’s why the right pane is blank. How do I know that? Because of the 0’s that show up in the open Type and Severity filters at the top of the page. This has nothing to do with where the file is located in the project.

Another way to approach this is from the Code view. E.G.


So you’re saying that there really are 0 issues in the file api/documenttypes?

So if i get to the issues in that file from other means besides the filter by file option I should also see 0 issues and not 38 code smells?

Like this?


That’s what your screenshot indicates.

Compare the file selection in the two different screenshots and you’ll find they’re different: “webchart:/api/docu…” versus “api/documenttypes.c”.

I can’t tell you more without understanding your project structure. I get the feeling you think I’m trying to pull the wool over your eyes. I’m simply reading the screenshots you provided.


This is why I’m trying to report the bug. I have no control over how sonar decides to display its file filter values. The fact that it shows 1 as a simple file path and another prefixed with the project and a colon is out of my hands.

Unless I’m massively misunderstanding sonar’s UI, I’m trying to report that sonar is saying 0 issues are in this file, while obviously from the last screenshot you can see that there are 38 code smells. I’ve provided the formatting of the relevant urls as a starting point which I think is related.

Compare these two workflows using the exact same project for each:

Showing No Issues

  • Click on a project (WebChart)
  • Click the issues “tab”
  • Open the “File” filter
  • Enter “documenttypes”
  • Select “api/documenttypes.c”
    ** We couldn’t find any results matching the selected criteria
    ** No other filters were applied

Showing Issues

  • Click on a project (WebChart)
  • Click the code “tab”
  • Enter “documenttypes” into the “search for files” filter
  • Select “documenttypes.c”
  • Verify sonar recognizes that the full path of this filename is: “api/documenttypes.c”
  • Click the “Code Smell” link that says 38
  • View resulting screenshot showing a list of 38 code smell issues on the right.

I don’t know why the filter values look different in the screenshots, but I’ve just given you the two workflows to arrive at each screenshot.

I can assure you this project only has a single file named “documenttypes.c” and it is located in the “api” subdirectory.

This issue discrepancy exists for every single source file contained in my “api” directory. The discrepancy also exists in a number of other directories as well, but for some reason not all of them.

  • Filtering by a file in a subdirectory named “webchartdb” -> url changes to issues?fileUuids=[VALIDUUIDFORMAT]&id=webchart&resolved=false and it shows issues
  • Filtering by a file in a subdirectory named “api” -> url changes to issues?fileUuids=webchart%3Aapi%2Fdocumenttypes.c&id=webchart&resolved=false and it incorrectly does NOT show any issues
  • Filtering by a file in a subdirectory named “messenger” -> url changes to issues?fileUuids=webchart%3Amessenger%2Fmessenger.c&id=webchart&resolved=false and it incorrectly does NOT show any issues

Hi @KaibutsuX,

Thanks for taking the time to report this. This is indeed a bug, and I opened a ticket here. We will try and fix it for the next release (8.5).

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.