Old lines detected as new code

I have a problem that seems similar to this issue: Issues being reported from old coude outside the new code threshold
However, that issue is about SonarCloud & TypeScript, whereas I’m using SonarQube on a Java project.
SonarQube version: 9.0.1.46107

In our project new code on feature branches/pull request is defined as compared to main branch. But more often than not, the SonarQube quality gate will fail on old issues, whereas it should only fail on new code. Upon inspection, the issues are not highlighted in yellow.
Sometimes this happens on old code in files that I’ve worked in (which would be a bit understandable, but still the blame information should prevent this), but it also happens in files that haven’t been touched for a long time.

For example:


This immediately raises my eyebrows, I don’t claim to be perfect but I wouldn’t introduce 704 code smells on 11 lines of new code.

Inspecting one of the smells:


As you can see, no yellow highlight, so this is not actually new code.

Blame information:
image
So this code dates from 2018. I’ve blurred out some potentially identifiable information but the issue should be clear.

When it’s only a few ‘old’ issues, it’s easy to ignore them and manually verify that there aren’t any issues with the code that you actually wrote. But when it’s 704 issues, this is not feasible.

I don’t know whether this is a bug in SonarQube, or I just don’t understand how it works. Any help would be greatly appreciated.

Hi,

Welcome to the community!

You said that your branch is baselined against main. Is it also rebased?

Is this ticket (fixed in 9.1) relevant?

SONAR-14929 - New Code using a ‘reference branch’ doesn’t detect changed code with git merge workflow

Is this one (expected in 9.3)?

SONAR-15697 - New code detection when using reference branch and rebasing doesn’t detect some commits on branch

 
Ann

1 Like

Hi Ann,

Thanks for your answer!

We do indeed rebase our feature branches and actually I noticed the problems referenced in those two tickets a few days ago. I’m glad to see that they are fixed or expected soon. But I think that they are not relevant to what I describe.
These fixes are about code that is actually new, but not detected as new code. The problem I’m describing is (almost) the opposite: issues on old code (that hasn’t been touched in years) suddenly affect the Reliability and Maintainability Rating of a feature branch.

To be clear: the old code is not detected as new code (no yellow highlighting, not included in lines to be covered), but the issues raised by the old code are reported as New Bugs or Added debt.

Hi,

Okay, well that’s a bit top-of-mind for me at the moment, so I wanted to ask.

Can you characterize or give a list of the rules in play here? Because it’s certainly possible to have new issues in old code when some other line is changed.

As an example, let’s say I have a class with only one reference to a member variable. That variable declaration was last edited in 2018. Then in refactoring I delete the only use of that variable. The next analysis will raise a brand new “unused variable” issue on that 2018 code. This is just one of many such scenarios. Does it sound relevant?

 
Ann

No worries. By mentioning it, you did provide a solution for another problem that I recently encountered but hadn’t had the time to investigate. So thank you for that.

As for your example, that does clarify things a bit, and it could explain some of the issues that I encounter, but not all of them. For example, I get ‘Remove this unused import’ issues in classes that I haven’t touched. In one case, the code that used the import was removed in June 2021.
When I look at my main branch (named ‘development’), the issue is there (first issue in this screen shot):

When I look at a feature branch that was started 14 days ago, and filter issues on new code, that same issue also shows up (first issue in this screen shot):

In the main branch, the issue was raised 4 months ago. In the feature branch that has changed to 13 days ago. But it’s the exact same issue, in a piece of code that I haven’t touched, called or referenced in my feature branch.
The same thing goes for the other issues in that second screen shot, and most (if not all) of the 704 issues on new code that SonarQube reports. An exhaustive list of all the rules in play would be too long, but here are a few of them (ignoring the ones that you can see in the screenshots above):

  • Subclasses that add fields should override ‘equals’ (no fields were added - or moved - to any subclass in the feature branch)
  • @Deprecated code should not be used (no new code was written that uses deprecated code, nor did I add the @Deprecated tag to existing code)
  • ‘throws’ declarations should not be superfluous

Another thing I noticed: if there are 704 new issues in my feature branch, the total amount of issues (not just new code but all code) should also increase by 704 (minus the issues that I fixed along the way). But the total amount in the main branch is 4168, and 4161 in the feature branch. And I’m certain that I didn’t solve 700 issues.

Leander

Hi Leander,

Could you check the date SonarQube has for the line one of those issues is on? E.G.
Selection_1065

Just FYI, we’ve got a lot new issues on old code for this rule right now because we’re doing some deprecation in this version. But okay.

Just to note, this is one of those that can be triggered by deleting code.

Yeah… there does seem to be something odd going on here. I’m going to flag this thread for more expert attention.

 
Ann

1 Like

Hi Ann

Both the feature branch and the main branch show the same date:
image

That’s good to know.

Okay. I appreciate the time and effort you took in troubleshooting this issue.

Leander

Hey @reneald,

I have a few questions I’d like to ask you to understand if your problem is somehow related to SONAR-14929 or SONAR-15697.

I see that the issues are appearing for you both on the main branch and on the feature branch.

  1. Are they appearing as part of overall code on the master branch, and as part of new code on the feature branch?
  2. Which new code definition strategy are you using for the main branch?
  3. Just to be sure: is Git your SCM?
  4. If so, for the feature branch: are there rebases on to the main branch? Are there merge commits?
  5. If so, when did they happen?

Thanks a lot for your help!
Belén

Hello Belén,

To answer your questions:

  1. The issues are appearing as part of overall code on the main branch. On the feature branch they are flagged as New Bugs, New Code Smells etc. on the overview page (see first screen shot of my first message). On the Issues tab they show up when filtering on new code (you can see the filter on the 3rd screenshot of the 5th message in this thread).
  2. We use Previous version on the main branch and Reference branch on all other branches
  3. Yes, we use GitLab
  4. Not in this particular case. We have noticed issues when rebasing, but the problem I’m addressing in this thread happens without rebasing.

As a side note, I had this problem happen in another feature branch. Not knowing about SONAR-14929 or SONAR-15697, I rebased onto the main branch just to make sure that everything was up to date. After the rebase, Sonar didn’t detect any difference between main and feature branch, which I think is the problem addressed in either SONAR-14929 or SONAR-15697 (being relatively new to Sonar I don’t understand the difference between the two tickets). This also made my problem disappear: no old issues were flagged as new on the feature branch.

Leander

Thanks a lot for sharing this information with us.

From what you’re describing, your issue does not seem related to SONAR-14929 (issues are not considered new after a merge happened on a branch using reference branch as its new code strategy) or SONAR-15697 (issues identified as new in SQ are no longer new if the branch is re-analyzed after a rebase on to the main branch took place).

However, the solution we’re proposing for these 2 issues may help. It consists on changing how we identify lines on a branch as new when using the reference branch strategy (we will now use git diff), and based on that only the issues appearing on those new lines will be considered new.

You can follow the progress of the fix here. I’ve linked your post on it as a reference.

Are there any steps you could share with us in order to help us reproduce your scenario?

A few things that could be useful for us to understand how to reproduce your scenario:

  • Let’s focus on one of the issues which are wrongly flagged as new.

You can select whichever you want. Its issue key will be available on the URL if you click on it: {SQ-URL}/project/issues?id={project-key}&open={issue-key}&resolved=false

Then you can query it on the SQ database by doing

select i.kee, 
i.line, 
i.author_login, 
i.created_at , 
i.updated_at, 
i.issue_creation_date,
i.issue_update_date
from issues i where i.kee = '{issue-key}'
  • Your git history of your feature branch
git checkout <your-feature-branch>
git log --decorate --graph --oneline --format=fuller

This data can be long list, so you can crop it to include the commit which introduced the issue you chose for the previous step.

  • Dates from the analysis on your feature branch
select s.*
from components c 
join snapshots s on c.uuid  = s.component_uuid
where c."scope" = 'PRJ' and c.kee = '{project-key}:BRANCH:{branch-name}'

Assuming your project key is project1 and your branch name is feature-branch, then your query would be

select s.*
from components c 
join snapshots s on c.uuid  = s.component_uuid
where c."scope" = 'PRJ' and c.kee = 'project1:BRANCH:feature-branch'

You can share this with me privately through a direct message. Feel free to obscure any sensitive data (like commit messages).

Hi Belén,
I can’t find out how to send a direct message. When I click your (or indeed any) avatar, I don’t see the direct message icon. I did reach trust level 1 yesterday so I think I should be able to send DM’s? Or maybe there are some other restrictions on my account?

Hey Leander,

I’ve sent you a PM thread, and now you should be able to reply back to me directly.

1 Like