Connected mode not noticing resolution changes

Get help SonarLint
#1

I have SonarLint 4.2.0.201909192007 on Eclipse (CodeReady) connected to an 8.5 SQ server. On the server, using the web API, I resolved one issue False Positive. On the SQ website, that project’s bug count then decreased by 1. Viewing the source code on the webpage, the line in question no longer has a bug icon next to it (it used to).

But it still shows up in CodeReady in both the SonarLint Report and in the source code panel. In the SonarLint Bindings view, I did Update All Project Bindings. I’ve also shut down and restarted both the SQ server and CodeReady (and rebooted both machines) to no avail. The connection uses token authentication, and if I change the token I get an authentication error as expected, which I don’t get with the correct token so the authentication should be OK. (With correct authentication, an update takes about 5-10 minutes so it seems to be doing SOMETHING.)

So I’ve read that false positives should not show up in SonarLint. Are there additional configuration steps I need, either in CodeReady or in the server (e.g., something to enable connected mode)?

#3

Hi @MisterPi

Here are a few things to look at:

  1. Is your issue marked as false positive (FP) on the main branch in SonarQube? SonarLint is currently only synchronizing issues based from the SQ main branch.
  2. Is the file path matching working properly? It is common that the file path in the IDE doesn’t match the file path in SonarQube. Especially for multi-module projects. Look at the SonarLint Bindings view. You should see your Eclipse projects bound to your SonarQube projects. The resolved prefix is displayed next to the Eclipse project name. This prefix is used to convert local path to remote path, that is required to query issues (see next point).
    image
    image1054×242 42.5 KB
  3. Another check you can do is to close/reopen the file containing the issue you think should be suppressed. In the SonarLint console, with verbose output enabled, you should see a successful WS call that is made to refresh server issues:
    image
    image1888×371 74.3 KB

If all the previous points are correct, I see a last possibility, that is a mismatch between the code you have locally, and the remote code on SonarQube. We have a few heuristics to try to match even with source code difference, but this is not 100% accurate. To verify this hypothesis, ensure that the code you have locally is the same than the one analyzed on the server.

1 Like
#5

Thanks. I got it to work. We have a collection of individual projects under a parent directory/folder. When we edited the bindings, both the parent and all the subprojects showed up in the window for selecting projects. We were selecting just the parent on the assumption that would give us everything. Apparently it doesn’t. (Maybe just the top-level pom and that’s it?) After selecting ALL the projects and updating, the issues we marked falsepositive disappeared from Eclipse.

One more thing: there are issues where we change the settings for a specific issue (NOT the entire rule), such as lowering the type and severity to minor smell, in cases where the code in question isn’t as worrysome as SQ thinks, but we still want to tag it so developers know it should be changed. But the popup in Eclipse/SonarLint when mousing over a marked line doesn’t change in any way. Is it supposed to, or is that feature not implemented in SonarLint?

#6

It is supposed to work for severities, but not for issue type. You may have to close/reopen the file in Eclipse to make the remote severity fetched again.
Note that the severity of an issue is only displayed in SonarLint “On-the-fly” view, and is different from Eclipse marker severity.

#7

OK, I can see that now. That seems counter-intuitive (i.e., that it works for severity but not type, when up to this point, it seemed that both are just properties, and you can do with one that which you can do with the other).

The tip box that pops up when I mouse over an underlined issue doesn’t show severity. Instead, it just shows a red circle with a horizontal line, which seems to match the one in the SonarLint On-The-Fly tab rather than one of the severity symbols. (Except that the bottom of the circle seems to be cut off in the tip box.) The severity shows up correctly in the On-The-Fly list, but, as you said, the type is still the default.

#8

For the record, we have a ticket about the missing synchronization of issue type, but it has never received a lot of traction: https://jira.sonarsource.com/browse/SLE-167
AFAIK changing issue type is not very common, and I think it is more likely to be removed from SonarQube than added to SonarLint.

If you are really interested by the feature, I suggest you open a new thread in the category “Suggest New Feature”, so that we could start collecting votes and use cases.

Yes, this is the SonarLint icon.

1 Like
Sync modified SQ issue type with SonarLint
#9

Actually, changing issue type is a VERY useful feature. There are many issues where a rule catches a lot of things that aren’t that bad. (See S2111 should check for integer equivalence for example.) We could mark them false positive, but we’d still like to direct attention to them, just not as urgently as the true bugs. So “demoting” them to code smells is one way to do that.

The security hotspot type was created, if I read your documentation correctly, to identify POTENTIAL vulnerabilities that could also be benign, but where automatic analysis is impossible. SQ metaphorically shrugs and says, “I don’t know, but you’d better take a look at this…” So again we may want to mark the benign cases as smells if we feel that the code could be done better (otherwise we’d mark it falsepositive).

#11

Link to the feature request: Sync modified SQ issue type with SonarLint

#12

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.