Issue reopened as new after changing/reverting rule config

I changed “Threshold” of the “Cognitive Complexity of methods should not be too high” rule(Java) -> scan my project -> revert the “Threshold” -> scan my project again, SonarQube displayed some “New Code Smells”, but I didn’t update any code, is it a bug?

Hi,

Nope, not necessarily. Because when you’ve analysed after changing the threshold, you might effectively have closed a bunch of related issues. When reverting the threshold those same issues get detected, but this time as new, since they were just closed beforehand.

Note that there are planned improvements in SonarQube to more gracefully handle transient/unintended closure of issues: Preserve issue tracking on closed issues. Should be coming in SonarQube v7.4.

The “Leak Period” setting is “BASELINE”, why SonarQube didn’t compare to “BASELINE” but “previous”?

Hi,

Issues are backdated in some situations, but not the one you describe. In practical terms, that means that when an analysis finds an issue that does not already exist, it creates a “new” issue. I.e. an issue dated with the timestamp of the analysis and that new issue ends up in the leak period.

So what you did was

Closed some old issues

Opened brand new issues.

Note that from 7.4 (E.T.A. end of the month) we’ll reopen those closed issues instead of creating new ones.

Ann

Hi,
This problem still exists?the closed question was recreated and the original tag was lost.
What do I need to configure?
sonarqube version:7.4


Hi,

I’m missing some context in your screenshots. For the issues you’ve marked, I would expect to see a line number in the issue block. If it’s there, it’s chopped off in the bottom screenshot, but it’s certainly missing in the one on the top. Here’s what I’m talking about:

Selection_343

SonarQube only omits that information when the issue has been reported at file level or above. So I find it rather odd that the specific issues you show lack that information. Additionally, line number is used in the algorithm that determines whether an issue is new or not, so if it’s missing… well that couldn’t have helped.

The docs describe the algorithm for deciding whether or not an issue is new. Maybe it will help you understand what’s going on.

 
Ann

yes,The line number is changed.the closed issue line number is 135,after editing the code, this line number becomes 136.
What I want to know is that the reopen algorithm line number needs to match exactly?
Is it possible to reopen those closed issues as long as the hash value is the same?
If I want to modify this matching algorithm, which source file should modify ?
thanks.

Hi,

I would think that your case would match in the second step described in the docs (linked above). But without more details it’s hard to know.

BTW, I finally realized that the line numbers are missing from your first screenshot because you’re showing the closed state. Really, without more detail - such as a screenshot of a suspect issue in the code in both the original and re-created states - it’s hard to say much more.

 
Ann

I want to reopen the closed issues even if the line numbers don’t match.Is there a way?