Issue started from yesterday, i.e. 3 Jun 2025.
No prior build pipeline configuration changes.
No workarounds yet identified.
Log snippet:
Starting: Run Code Analysis
==============================================================================
Task : Run Code Analysis
Description : Run scanner and upload the results to SonarQube Cloud.
Version : 3.3.0
Author : sonarsource
Help : This task is not needed for Maven and Gradle projects since the scanner should be run as part of the build.
[More Information](https://docs.sonarcloud.io/advanced-setup/ci-based-analysis/sonarcloud-extension-for-azure-devops/)
==============================================================================
C:\a\_tasks\SonarCloudPrepare_xxx\3.3.0\classic-sonar-scanner-msbuild\SonarScanner.MSBuild.exe end
SonarScanner for MSBuild 10.1.2
Using the .NET Framework version of the Scanner for MSBuild
Post-processing started.
...
INFO: Importing results from 8 proto files in 'C:\a\1\.sonarqube\out\17\output-cs'
INFO: Importing 46 Roslyn reports
INFO: Found 46 MSBuild C# projects: 41 MAIN projects. 4 TEST projects. 1 with no MAIN nor TEST files.
INFO: Sensor C# [csharpenterprise] (done) | time=103337ms
INFO: Sensor Analysis Warnings import [csharpenterprise]
INFO: Sensor Analysis Warnings import [csharpenterprise] (done) | time=0ms
INFO: Sensor C# File Caching Sensor [csharpenterprise]
INFO: Sensor C# File Caching Sensor [csharpenterprise] (done) | time=0ms
INFO: Sensor C# Tests Coverage Report Import [csharpenterprise]
INFO: Parsing the Visual Studio coverage XML report C:\a\_temp\TestResults\xxx\xxx.08_56_49.coveragexml
INFO: Adding this code coverage report to the cache for later reuse: C:\a\_temp\TestResults\xxx\xxx.coveragexml
INFO: Coverage Report Statistics: 5601 files, 3916 main files, 3916 main files with coverage, 1685 test files, 0 project excluded files, 0 other language files.
INFO: Sensor C# Tests Coverage Report Import [csharpenterprise] (done) | time=254898ms
INFO: Sensor JsSecuritySensorV2 [jasmin]
INFO: 519 file(s) will be analysed by SonarJasmin.
In the interests of transparency, I need to update you that it may be a bit longer for the fix. We’ve actually got another incident ongoing in addition to this, and that one is blocking the fix for this one.
We’re as eager to address this as you are, and we’ll get the fix deployed as soon as possible.
This seems to be happening again in a Typescript project with about 500 .ts files.
We’re using sonar-scanner-cli-5.0.1.3006-linux and running in CircleCI. It’s a closed source project, but I can share a link to our SonarCloud project with you privately if you’re interested. The logs end with:
INFO: Sensor JsSecuritySensorV2 [jasmin]
INFO: 446 file(s) will be analysed by SonarJasmin.
INFO: Analysis progress: 9% (44/446 files)
INFO: Analysis progress: 19% (88/446 files)
INFO: Analysis progress: 29% (132/446 files)
INFO: Analysis progress: 39% (176/446 files)
INFO: Analysis progress: 49% (220/446 files)
INFO: Analysis progress: 59% (264/446 files)
INFO: Analysis progress: 69% (308/446 files)
INFO: Analysis progress: 78% (352/446 files)
Too long with no output (exceeded 10m0s): context deadline exceeded
This started failing again yesterday. Based on timestamps, the above “Analysis progress” lines were printed around 2025-06-17T21:21:05Z, and then CircleCI killed the job after 10 minutes with no logs.
We did roll this back out this week after some mitigations. Could you add -Dsonar.verbose=true to get a debug log and provide it here to help us improve the engine’s performance?
And once you’ve done that, if you’d like to fall back to the old behavior, you can swap that flag for -Dsonar.jasmin.internal.disabled=true to use the old engine.
Thanks for the tip about verbose mode. I can see which files it’s getting stuck on.
It’s hanging for ten minutes on the 395th file out of 446, a short file, 46 lines, .js, but it’s the entry point for an express server, so it’s importing a routes.js, which is then importing a bunch of other files that were previously analyzed.
There isn’t much else to see in the logs. I’ve scrubbed them the best I can and I can share them privately if you’re interested.
I tried updating the Sonar Scanner CLI from 5.0.1 to 7.1.0 just in case. I also ran from the command line to get past the 10 minute no-output timeout: it takes 1h27m for that one .js file and 8m16s for another .ts file. The rest are fast.
The whole analysis completes in 1m20s total with -Dsonar.jasmin.internal.disabled=true.
We are very interested in resolving this issue in the new JS security sensor. In the meantime, the switch sonar.jasmin.internal.disabled=true should help you work around this issue.
You shared:
It’s a closed source project, but I can share a link to our SonarCloud project with you privately if you’re interested.
as well as
There isn’t much else to see in the logs. I’ve scrubbed them the best I can and I can share them privately if you’re interested.
Yes, I would be very interested in both of these to help resolve the issue in the new JS security engine. Could you please send them to me via PM? Thank you!
We are already investigating the issue and will release a fix asap, but there is no ETA.
To help us investigate, could you provide us with more information on the issue you’re facing? How long did your analysis take previously, and how long does it take now?
Also, could you please provide us with some debug logs? You can pass the option -Dsonar.verbose=true to the scanner to obtain a verbose output that will help us help you.
Hi Malte,
Previously the analysis use to take about 2 minutes to run and right now hangs at sonarjasmin analysis, and then github actions cancels the job after 36 min.
