We have recently installed an on-prem SonarQube sever (Developer Edition, version 10.1.0.73491, under a Windows Server VM), running scans manually on workstations (without integration with any CI/CD pipeline). The scans of JS code run correctly, yielding both Issues and Security Hotspots, reflected in the server Web interface.
We also installed SonarLint (v. 3.21.0) under VSCode (v. 1.81.1) on a Windows 10 machine and defined an interface to the SonarQube server.
The connection seems to have succeeded: according to logs appearing in the “Output” tab of VSCode, the rules are fetched, and so are project branches, issues, taint issues and hotspots. All the messages appearing in the “Output” tab are of “Info” level.
However, neither hotspots, nor issues are shown in the VSCode workspace. Instead, the Security Hotspots section shows a message “Please ensure a connection to SonarQube 9.7+ or SonarCloud is set up…”, and “Problems” tab shows nothing.
Running SonarLint directly on the source code (by selecting “In Whole Folder” option) works, filling both Security Hotspots and Problems, but without any sync with the server definitions.
Our network, servers and workstations are working in a closed and hardened environment, so it is possible that some Data Security tool is interfering with the process. Please advise how it is possible to troubleshoot the problem.
Hello @greg_ya and welcome to the community!
Thanks for your detailed report. Can you please ensure that verbose logging is enabled for SonarLint? And after it’s done please open the project that is bound to SonarQube and then open the file with the code in the VSCode editor.
Once you have done it please copy the log output and upload it here as txt file.
Have a good day!
SonarLintLogs.txt (295.8 KB)
Hi, Kirill,
Thank you very much for your help!
I did as you said, the log file is attached. Also attached is a screenshot from the SonarQube UI, where you can see a vulnerability detected in Worker.js, and a screenshot from the SonarLint page, where no Security Hotspots are shown even after I opened Worker.js in the workspace, as you suggested.
I guess our problem is that the sonarqube/api GET’s (appearing in log lines 2357, 2361 and 2365) are returning empty results. I tried to run them manually from a browser, and received some very short binary response (a protobuf with no results?). Tried manually to set the “changeSince” in the URL parameter to a small value, but got exactly the same result.
Regards,
Greg.
Hi Greg,
What I see from the log is that your SonarLint instance pulling for the correct branch which is main, but getting an empty response. This is a bit strange for sure, given you can see the issue in the SonarQube web interface. And I don’t see any errors in logs or other signs why is it this way.
I’ll try to find what are possible reasons and how can you troubleshoot it. I will keep you posted here on this topic.
But regardless of server synchronization results, you are still supposed to have local analysis. Yes, server data about issues will not be taken into account. Like if you marked the issue as Won't fix during review for example. Normally such resolved issues should disappear in SonarLint, in your case they won’t. But issues still should be there. And here becomes relevant the fact that the log you have posted does look truncated to me.
The last lines of your logs are related to the JavaScript/TypeScript analyzer warming up and preparing everything for analysis. So after you are supposed to have a little bit more logs about warming up JS/TS analyser and then local analysis. On my machine, when I run the analysis the first time after IDE restart, I can see it stops printing logs for the noticeable time exactly after the line that is the last one in your log. It’s waiting for the initialization of everything it needs to have to start the analysis. But then it continues and performs the analysis (on my box).
So question. Could it be that you have copied logs during such a warmup pause on your machine? Can you please try again and give it a bit more time? Really ensure it doesn’t print anything after. After warming up, further analysis iterations should be significantly faster, but initialization may take time.
Best,
Hi, Kirill,
Yes, you are right, I just did not wait enough. SonarLint did try to scan the file locally, but eventually failed as well.
There is a lot of bulk printouts in the log file, I tried to cut only the lines which seem to show a reason for the failure. My guess would be that line 50 is showing that reason: RUNTIME_API_INCOMPATIBLE, whatever it means…
Thanks!
Greg.
SonarLintLogs1.txt (7.2 KB)
Hi, Kirill,
Hate being pushy, but any chance you were able to have a further look into it?
Thanks,
Greg.
Hi Greg.
The new log you submitted makes me think that something unexpected happened during the analysis.
I have asked my colleagues who work on JavaScript/TypeScript analysis to look at this. They will do it when they have time.
In the meantime, you could check if you have issues with other languages like Python for example. You don’t need to have Python installed on your machine. It will be enough to create a .py file in your project and put there some code that is supposed to have issue(s). Something like
def myFun():
# TODO foo bar
i = 0
print('Hi')
j = 0
should do the job.
If you can see the issues for the Python code it means that the problem is specific to JS/TS.
Best,
Hi, Kirill,
I made some more experiments, including a Python file, as you suggested. I created a “hardcoded IP address” vulnerability in Python, and it was detected both in SonarQube Web UI and in a local SonarLint VSCode run. I also made some more experiments with JS files. This time the local SonarLint JS runs succeeded as well, maybe Python file being in the folder made the difference.
After all this I think I managed to focus the problem to the following:
For some reason, SonarLint only shows hotspots or problems from its own runs. Either “In Open Files”, or “In Whole Folder” - whatever option is selected for display. But it never shows the issues stored in SonarQube server, even though (according to logs) it succeeds fetching them with /api/hotspots/pull calls.
Here for example (the 1st log file that I sent), we see it receiving 59 hotspots:
[Debug - 07:38:19.372] GET 200 http://XX.XX.XX.XX/sonarqube/api/hotspots/pull?projectKey=NeWMI-2&branchName=main&languages=apex,c,cpp,css,cobol,web,java,js,php,plsql,py,secrets,ts,xml,yaml,go,cloudformation,docker,kubernetes,terraform | response time=118ms
[Debug - 07:38:19.378] Pulled issues in 124ms
[Debug - 07:38:19.407] Merged 59 hotspots in store. Closed 0. | took 26ms
59 hotspots were fetched, but they never showed up in VSCode. This goes both for JS and Python code.
So, there might be a problem in the local SonarLint JS scanner (sometimes fails to run). But our real problem is causing SonarLint show issues exposed by SonarQube server, and not those collected locally.
Thanks,
Greg.
Hello @greg_ya,
Many thanks for the feedback and the logs you provided. That helped a lot!
A subset of JavaScript rules uses TypeScript’s compiler to benefit from type information and improve their analysis precision. When type information is missing, these rules can find (less) issues to some extent or just don’t do anything at all. The exact behavior depends on the rule implementation, and it’s a case-by-case decision depending on what’s doable.
For performance reasons, type information is available in SonarLint only for projects of a certain size. More specifically, the property sonar.javascript.sonarlint.typechecking.maxfiles (default 20’000 files) controls the enabling of type-checking JavaScript files. This means that JavaScript rules using type information become no-op should the threshold be exceeded.
Now, coming to your specific case, the security hotspot highlighted on the provided SonarQube screenshot happens to use type information. Furthermore, the logs that you kindly shared include the following lines:
[Debug - 07:40:16.508] Project type checking for JavaScript files deactivated as project has too many files (maximum is 20000 files)
[Debug - 07:40:16.508] Update "sonar.javascript.sonarlint.typechecking.maxfiles" to set a different limit.
This essentially means that JavaScript rules using type information won’t behave as expected.
Please try to set in SonarLint the property sonar.javascript.sonarlint.typechecking.maxfiles to a value higher than 20’000 until the issues are found. Note, however, that increasing that value could degrade the analysis running time and performance depending on your project size and the available memory.
Finally, we are aware that the printed logs are not helpful from the user’s perspective. We created this ticket to improve those as well as that ticket to help identity which rules are impacted when type information is missing. We will also solicit our Documentation team to document this limited feature in SonarLint’s context.
Hope this helps,
Yassin
Hi, Yassin,
Thank you very much for your help! I will try to change the property to a higher value. It will be helpful to have SolarLint check the entire JS project, without size limitation.
However, please notice that this problem is just a by-product of troubleshooting of another one: SonarLint fails to show issues found by the external scanner and reported to an on-prem SonarQube server (see my previous response to Kirill). Do you have any idea what is the problem there?
Regards,
Greg.