New code smells on files without any edits

Dear SonarQube Community,

Our team is facing an issue with code smell detection in SonarQube.
Sometimes code smells are identified as “new” even when the files have not been modified in months or even years.

Let’s take this example:
A file called has been modified on 11 DEC 2020.
In SonarQube this file contains a “new code smell” (in the last 30days). This is confusing because the has not been touched.
This behavior is not consistent: sometimes “new code smells” suddenly appear from old files and sometimes we see only the code smells we expect from new commits.
In the screenshot you can see the history of the resolution wich jumps back and forth to resolution changed to fixed and resolution removed (was fixed).

We are using Bamboo to build the code and trigger the SonarQube analysis. Shallow clones is not enabled meaning the full git history is being fetched.

  • SonarQube v8.6 Developer Edition
  • sonar-maven-plugin:

Can someone explain this behavior? Is something wrong with our SonarQube setup or are we not understanding how this works?



Welcome to the community!

First, thanks for a thorough set of screenshots. Unfortunately, you’ve blurred out the issue message, so it’s impossible to guess what rule is involved.

There are a couple possible explanations for this type of behavior:

  • Some setting is toggling back & forth the source file’s inclusion in what’s analyzed (sounds far-fetched, but I’ve seen it)
  • Other, related code was modified that impacts whether or not there’s an issue. E.G. I deprecate a method. Without being touched all the uses of that method have new issues about uses of deprecated code.

Does either scenario seem feasible? And if not, can you characterize the rules in question?


Hey G Ann,

thanks for your answer,

I’m Sander, I’ll replace Charlie and will follow up on this issue at our clients side,

I’ve added two screenshots:

I guess you don’t have enough info now to know what is going on
and I do hope you can aid us in getting the information you need?

Thanks a bunch for your first answer & best regards,


Hi Sander,

Thanks for the new issue screenshot. What I was really after is the underlying rule. Based on a search for the message text that’s visible, I’m guessing it’s S3252, which is about how a child class uses static members of the base class. Now, with the understanding that this is about the interaction between two different classes, it’s easy to extrapolate that someone probably made a change in the base class which retroactively created a problem in the child class.

Does this make sense?