Analysis hangs at "will be analysed by SonarJasmin" on Azure DevOps Pipeline

Analysis hangs at “n file(s) will be analysed by SonarJasmin”.
Left for hours, yet does not progress beyond this log message.

  • Build Pipeline: Azure DevOps
  • Visual Studio Project: ASP.NET MVC C#

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.
2 Likes

We are having the same issue. The build will eventually cancel and fail after about an hour because of a timeout.

2 Likes

I’m experiencing the same issue.
As a temporary workaround, I have to exclude the JavaScript files to keep things working.

1 Like

Hey everyone.

Thanks for the reports. I’ve raised the alarm internally. I’ll update here when I have more info.

1 Like

Hi all,

This is the result of the deployment of updated analyzers. We’re working on reverting the change. Hopefully this should take effect in an hour or two.

 
Ann

2 Likes

Hey @mdridder and @chungvtran,

to help us investigate the performance regression, can you share a bit of context of your analysis similar to @BDRichardson?

  • What kind of project are you analyzing?
  • What Scanner and CI are you using for the analysis?
  • Is your project open-source? If so, please share a link

Any information helps to solve the problem. Thanks in advance.

Nils

We are also experiencing the same issue with the same scenario

  • Build Pipeline: Azure DevOps
  • Visual Studio Project: ASP.NET MVC C#

One thing I picked compared to the last successful build

Hanging/Failed – JsSecuritySensorV2 [jasmin]
Successful – JsArchitectureSensor -

Same problem here.

Hi again,

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.

 
Ann

2 Likes

Facing same issue. Allowed longer build times to unblock development, but this is quite impactful.
Eagerly awaiting that rollback…

Hi all,

The revert is complete.

 
Ann

2 Likes

Seems to be working again for us now.
Thank you for resolving so promptly.

Thank you for the confirmation!

To those that reported here, would you mind sharing a bit more information to help us identify the root cause? see @Nils_Werner 's message above.

Full analysis logs would also greatly help. If you’re Ok with sharing them, I can open a private conversation.

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.

Hi @ms1111,

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.

 
Thx,
Ann

1 Like

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.

1 Like

Hey @ms1111 ,

thank you for this report! :folded_hands:

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. :slightly_smiling_face:

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!

1 Like

Hi! I’m facing this same error on github actions. In a node.js project. Is there any estimate of when this will be fixed?

Thank you!

Hey @tatah ,

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. :slightly_smiling_face:

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.