SonarQube E-mail Notifications Count Only for One Folder


  • Running SonarQube
  • Receiving incorrect issue counts for new issues

We have a project setup along the lines of Project A consisting of folders A_A and A_B; A_A is the main app folder, A_B is a static library that gets built & scanned in the context of project A.
When a commit generates (for example) one issue in A_A and 133 issues in A_B the new issues e-mail I receive (as an administrator for that project) will only list one issue for the author - skipping the other 133. The same happens for the “my new issues” notification e-mail the author receives.
From what I’ve investigated, this seems to be a case of:

  • either the separate folder isn’t taken into consideration, in which case it should
  • alternatively, I see that the e-mail link ends in createdAt=2022-09-30T19%3A39%3A40-0400 - which points to a very specific time and it might just be the case that, because of processing delays, the other issues have a slightly different time

Can you please confirm whether this behavior is intended, buggy or if it might be an issue with our configuration?


Are you subscribed to “New issues” or “My new issues” on the project? Because your “My Issues” notification should be the issues that are raised on lines where you’re the last committer.

On the other hand, if your subscription is to “New issues” then I would ask if the issues are “new” (raised in the New Code period) or not.



I’m the instance administrator and I subscribe to all new issues on said project. My coworker who triggered the large number of issues is only subscribed to his new issues. No other commits occurred there during that day so all of the issues were his - yet we both got the issue count only for one folder, not for the second.


Hi Adrian,

Were the “missing” issues considered new by SonarQube? That is, were they raised as “new” issues in the New Code Period? Did they show up on the New Code tab of the project homepage?



Yes, I haven’t checked each and every one but I did check a couple and they were marked as new code. They were also pulled by an automated script via API.


Thanks for getting back to me. I’ve referred this for more expert attention.


Warm welcome @Adrianh ,

We have troubles reproducing the issue that you are having. Could you provide following information to help us troubleshoot?

  1. What edition of SonarQube do you have?
  2. How do you scan the project? Could you provide us the configuration of your scanner?
  3. What is the type of issues raised? Are any of these issues security hotspots?
  4. Could you confirm if the new issues raised in your project all have OPEN status?

Hello, @Lukasz_Jarocki,

  1. We were running SonarQube, I just upgraded to before I received the notification on your reply
  2. It’s called via command line; build-wrapper is called with the main project Makefile as an argument (make -f project_name/Makefile) - which will also build and statically link sources from folders a,b,c,d - and then sonar-scanner with the following config (heavily redacted, I’m afraid, but I did leave all the configuration keys in place):
sonar.projectKey=project_name #REDACTED

# --- optional properties ---

# defaults to project key
#sonar.projectName=My project
# defaults to 'not provided'

# Path is relative to the file. Defaults to .
sonar.sources=project_name,a,b,c,d #REDACTED

# Encoding of the source code. Default is default system encoding


sonar.svn.username=<username> #REDACTED
sonar.svn.password.secured=<password> #REDACTED

  1. Code smells and bugs, there might have been one or two hotspots but the main issue is a large number of code smells passed under the radar
  2. Yes, they’re all in OPEN status; some time later they are moved to CONFIRMED by a separate script - think a matter of days, not minutes

One thing I have in mind is that, for this project, I initially only scanned the main folder (so the project included only the files under project_name without having the project_name folder under the code tab) then modified the file to include all the separate folders (so the project would now list under code folders project_name,a,b,c,d) - could this have messed up some internal references? Would there be any point in recreating the project? (I’d rather not in order to keep history intact but I can do it if it’s necessary)

Also, there are 20+ folders in the sonar.sources list - could the number be too high?

the list of 20+ should not cause rather any issue.

Thank you for providing additional information. We will get back to you when we find something interesting to share about the issue.

Hello, @Lukasz_Jarocki @ganncamp

For some reason the notifications now seem to be working correctly after upgrading to 9.7 - I was able to confirm correct functionality for two days in a row.

Thank you,

1 Like

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