Incorrect LOC shown in Licence Configuration

Hey @nkojuharov, thanks for reporting this. I think you just found a bug.

To confirm, could you please run this SQL query on your database, and tell us if the query returns any rows? I don’t need you to post the result here, I only need to know if the query found any results.

SQL
select loc_grouped_branches.projectUuid,
        loc_grouped_branches.projectName,
        loc_grouped_branches.projectKey,
        loc_grouped_branches.ncloc as loc,
        p.ncloc
    from (
       select pb.project_uuid as projectUuid,
       p.name as projectName,
       p.kee as projectKey,
       pb.kee as branchName,
       pb.branch_type as branchType,
       lm.value as ncloc,
       row_number() over (partition by pb.project_uuid order by lm.value desc, pb.uuid asc) row_number
       from live_measures lm
          inner join project_branches pb on pb.uuid = lm.component_uuid
          inner join projects p on p.uuid = pb.project_uuid
          where lm.metric_uuid = (select uuid from metrics m where name = 'ncloc')
          and p.qualifier ='TRK'
      ) loc_grouped_branches
    inner join projects p on p.uuid = loc_grouped_branches.projectUuid
        where loc_grouped_branches.row_number = 1
        and loc_grouped_branches.ncloc != p.ncloc
    order by loc_grouped_branches.ncloc desc

If this returns any result, it means that some branches from your projects were deleted (manually, or through an automatic purge for inactivity), and the “new” LOC score for the project was not correctly updated after the purge. If my assumption is correct, if you compute the sum of diff between the loc and ncloc columns, you will find the same gap you already noticed between SQ UI and api/projects/license_usage.

In this case, as a workaround, you can re-analyze any branches from the projects found in the query: the new analysis will fix the LOC count for the project.

3 Likes