Unexpected issue lifecycle behaviour

[yoxo...@gmail.com]

Hello,

the Sonarqube 5.6 documentation [1] explains the algorithm how new issues are detected. After some simple tests, I have trouble understanding that "3 of 4" criteria, as SonarQube seems to behave differently.


For example, using a minimal Java Quality Profile only with squid:S00103 (Line length) and squid:S109 (magic numbers). Analyzing the following code results - as expected - in two new issues.

  // rev.1
  public void test() {

    int magicNumber = 42;
       
    String s = new String("Very long line that does not meet our maximum 120 character line length criteria and should be wrapped to avoid SonarQube issues.");
  }

Let's say both issues found in rev.1 are resolved as "Won't Fix" in the UI. Later, the method is refactored or rewritten, resulting in something like rev.2:

  // rev.2
  public void test() {

    System.out.println("Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque vel diam purus. Curabitur ut nisi lacus....");

    int a = 0;

    int x = a + 123;
  }

A new Sonar analysis shows no issues for that code, although it is completely different. For both violations previously found, the line number, the message and the line hash have changed - therefore I'd expect new issues, if I understand the docs [1] correctly. Please help me understand what is going on here.

Using SonarQube 5.6.5 with Java Plugin 4.4.0.8066.

Best regards,
Roland


[1] https://docs.sonarqube.org/display/SONARQUBE56/Issue+Lifecycle

[yoxo...@gmail.com]

Hello,

a statement or clarification would be very appreciated, this question is blocking our SonarQube rollout.

Maybe I have a basic misunderstanding of the workflow, or missing something else. Please help me understand what's going on here.

Best regards,
Roland

[Julien Lancelot]

Hi,

Could you have a look at the scanner log and check that the file has not been excluded ?

Regards,

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/54ff6eb3-6f61-4cdc-b9f2-3697862d6cfc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Julien LANCELOT | SonarSource

http://sonarsource.com

[yoxo...@gmail.com]

Hi,

the scanner log contains no mentions of exclusions. The (only) class in the module does show up:

[INFO] Java Main Files AST scan
[INFO] 1 source files to be analyzed
[INFO] Java Main Files AST scan (done) | time=35ms
[INFO] 1/1 source files have been analyzed

Regards,
Roland

[Julien Lancelot]

Could you check that when starting an analysis on the project with the modified version and on an empty database you get the issue you're expecting ?

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/79b1f786-b23c-47f6-b309-2574b96de784%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[yoxo...@gmail.com]

What do you mean by "empty database"?

I tested this with a fresh 5.6.5 installation, hence no previous history of the test project. Test steps are as described in first email: 1.) First analysis 2.) set resolution, code change 3.) second analysis

[Julien Lancelot]

I mean, could you try to restart from the beginning without the first step, to be sure that the issue will be generated.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/b79fd4c5-815e-4208-ac33-b158e4364df2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[yoxo...@gmail.com]

Yes, they are. Both issues show up in an analysis of the altered code. (as expected)

[Julien Lancelot]

Hum, then there's something strange...

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/f1494da9-0a5a-4d5c-a98a-7a5210936793%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[yoxo...@gmail.com]

Please let me know if I can assist in some way to investigate this issue. Our SonarQube rollout is still blocked...

BR,
Roland

[yoxo...@gmail.com]

Hello,

the very same problem still exists in SonarQube LTS 6.7.0 with sonar-java-plugin-4.15.0.12310 and can be easily reproduced. SonarQube LTS seems to happily produce false negatives here.

Since the definition of a "new" issue [1] has not changed between 5.6 LTS and 6.7 LTS, I still consider this a major bug and wonder why this gets no attention from the SQ developers...

Kind regards,
Roland


[1] https://docs.sonarqube.org/display/SONAR/Issue+Lifecycle

[G. Ann Campbell]

Hi Roland,

The reason this gets no attention is that it's like Bigfoot. There have been scattered reports over the years, but no reliable proof. If you can indeed easily reproduce this, we would love to have your steps or reproducer project.

Thx,

Ann

[yoxo...@gmail.com]

Hi Ann,

sorry for the late reply. I created a project which should help reproducing this: https://github.com/rlaun/sonarqube-bigfoot

The README describes the steps; please see also the first post in this thread.

BR,

Roland

[G. Ann Campbell]

Hi,

Thanks for this reproducer project. The name gave me a giggle. :-)

I've run through this and can now answer two questions:

1) After I mark the issues Won't Fix, 'the "overview" dashboard still shows 2 code smells. why?' - Because the values shown on a project homepage are Metrics and Metrics are (currently) only updated during analysis. In short, the values are stale and this is the way it has always worked. (Look for this to change in 7.0)

2) Why don't I have issues on the re-analysis of the updated project? - Actually you do. The two issues you marked WF remain. They've moved with the code refactoring, so your 'line too long' issue is now attached to line 11, and your magic number issue is now attached to line 15. 

The question I can't answer is why issue move (which is designed to prevent issue churn as code is refactored) was this aggressive.

Ann

[yoxo...@gmail.com]

Hello,

Thanks for your answer.

ad 2.)

Sorry, I still don't get it. What happens here clearly contradicts the "three of four criteria" from the Sonar documentation ... or at least my interpretation of it.
For both issues, only 1 out of 4 criteria does match (the rule) while 3 have changed (line number, hash and message). Since the code in rev2 has changed drastically with respect to rev1, Sonar not finding any *new* issues make no sense to me.

BR,

Roland

[Julien HENRY]

Hi Roland,

I have updated the documentation of the issue matching algorithm that was outdated. The second step with block move detection was missing, as well as the last step were only 2 criteria are matched (since 2.11 !): see https://jira.sonarsource.com/browse/SONAR-2812

I also used your reproducer to investigate why issues were matched, and I found a nasty bug. See more details in the ticket:

https://jira.sonarsource.com/browse/SONAR-10194

It will be fixed in 7.0, and I will also ask for having it backported in 6.7.1.

A huge thanks for providing this reproducer!

Julien

[yoxo...@gmail.com]

Hi Julien,

glad I could help. The backport of the fix to LTS is great news!

Thank you very much - also for updating the documentation.

Cheers,
Roland

[fanny....@gmail.com]

Hello, I have a question about issue lifecycle, how to track and old issue and new issue in issue lifecycle? I hava asked at stackoverflow and I got this link.

I guess I am out of topic, so I will share link to my question.

Thank you.

https://stackoverflow.com/questions/48376665/issue-tracking-sonarqube-6-7?noredirect=1#comment83761328_48376665

[G. Ann Campbell]

Hi,

After reading the thread, what, if any, questions remain?

Ann