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:

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:
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.

1 Like


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


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.


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?


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.


Hi Leander,

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

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.


1 Like

Hi Ann

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

That’s good to know.

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


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!

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.


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.created_at , 
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

Hi. I’m facing a very similar problem. I’d like to know if you have any new information.
Some issues are being detected as “new code” on several different projects. Although Sonar detects it “2 days ago”, the last changes in these classes are more than 4 years old.

I’m using Version 8.9.6 (build 50800). We’ve began noticing the problem after implementing the workaround described in False positive on S1206 - #6 by michele.lorenzini (SONARJAVA-4023). We’re not sure if this issue is solved on version 8.9.7. However, we are not sure that the new code problem is related with the workaround (add a path to vm.jar on sonar.java.libraries), since the problem still exists after undoing it.

1 Like

Hi there,

both @ganncamp and @Belen_Pruvost seem to agree that this issue is related to how Sonar compares code on a feature branch with main branch. They and I could not be 100% sure because I couldn’t consistently replicate the issue, but all signs point in that direction.

The way that Sonar does the comparison has been changed in version 9.3 (you can find a more detailed description in the issues linked in @ganncamp 's first reply on this thread). I have literally upgraded my SonarQube instance a few minutes ago, so I haven’t had time to check for improvements on my end.

I realize that this isn’t terribly useful information. I would suggest reading the descriptions of the issues in @ganncamp 's post, and see if they resemble your specific situation. If they do, an upgrade to 9.3 should solve your problem.

Good luck!


i am using sonarqube 9.5 and i see the same issue where old code is highlighted as new code in pull request analysis.

and issues are reported on lines that were not changed in the pull reuqest.

version control - github.com
sonarqube - 9.5
branch community plugin 1.12.0
ci - jenkins

Hi @Nishwal_Shetty,

Please create a new thread and include your full analysis log.


@ Leander Van Reeth Hi,I has the same problem,how did you resolved the problem later?

This was solved for me by upgrading to 9.3.


I will try it,thank you!