Discrepancy between LOC limit error and Billing dashboard on main branch

SonarQube Cloud
1

We are trying to run the standard analysis on our main branch, but the pipeline is currently failing due to a license limit error. However, the numbers in the error message are confusing and don’t match our billing dashboard.

The analysis fails with the following error details:

This analysis will make your organization ‘xxx’ reach the maximum allowed lines limit of 300000. Current LOC usage is: 0. LOC count in this analysis: 316000. Language distribution: css=200,docker=37,js=64,shell=6,ts=313600,web=426,xml=754,yaml=913 Please contact the administrator of the organization to resolve this issue.

However, when I check the Billing and Usage section in SonarQube Cloud, it shows completely different numbers:

Lines of code used 231.365k private lines of code analyzed within 1 projects

My Question:

  1. Why does the error message state Current LOC usage is: 0 while the billing dashboard shows 231.365k?

  2. Assuming these 316k lines actually exist in the current analysis scope, what is the best way to identify exactly where they are coming from? Is there a log or a debug output that shows which specific directories or files make up this large count (especially the TypeScript files), so we can verify this and adjust our sonar.exclusions if necessary?

Any help to understand this discrepancy and get our main branch analysis running again would be highly appreciated!

2

Hey @patdreis, welcome to the Community!

The Current LOC usage is: 0. LOC count in this analysis: 316000 message is excluding the current project in its Current LOC count. Since you only have 1 project, this leaves 0 in the count. If it didn’t exclude it, it would tell you Current LOC usage is: 231365. LOC count in this analysis: 316000, which would also be confusing because it would imply you would end up with the sum of both. If the current LOC was not only 1 project but several, the difference might be even more elusive. Does this make sense? I will still bring it up to the devs, though, perhaps they can think of a clearer way to communicate this.

Regarding the 316k lines in your project, you could try to gain some extra insight by running the analysis with debug-level logs. The exact way to enable this may vary depending on how you’re invoking the scanner/which scanner you’re using, but generally setting the sonar.verbose=true property (or -Dsonar.verbose=true CLI parameter) does the job. Another idea would be to check the Scanner context for the background task associated with this analysis.