Failed analysis ID “99bdf6b6-a76e-4a4a-abec-06349279392c”

  • ALM used (GitHub)
    • We use Git LFS to store some large assets alongside the code
  • CI system used (GitHub Actions)
  • Scanner command used when applicable (automatic scan)
  • Languages of the repository (TypeScript/JavaScript)
  • Error observed (wrap logs/code around with triple quotes ``` for proper formatting)
    Last analysis failed Analysis ID “99bdf6b6-a76e-4a4a-abec-06349279392c”

Previous to re-adding the private repo to our SonarCloud instance, scans had last run on November 21st.

Latest attempts at analysis are failing with:
Your analysis with ID “AYUL84mzDqjtgypgapLi” has failed: the analysis of your project exceeded the maximum memory available for Automatic Analysis.

I’ve also attempted to run sonar-scanner manually.

The last few lines before the process appears to hang are:

16:49:02.940 INFO: Project root configuration file: NONE
16:49:02.952 INFO: SonarScanner
16:49:02.952 INFO: Java 11.0.17 Homebrew (64-bit)
16:49:02.952 INFO: Mac OS X 12.6.1 aarch64
16:56:04.141 DEBUG: eslint-bridge server closed
16:56:04.141 INFO: Time spent writing ucfgs 5112ms
16:56:04.149 ERROR: isAlive was interrupted
java.lang.InterruptedException: null
	at java.base/java.util.concurrent.CompletableFuture.reportGet(
	at java.base/java.util.concurrent.CompletableFuture.get(
	at org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl.isAlive(
	at org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl.heartbeat(
	at java.base/java.util.concurrent.Executors$
	at java.base/java.util.concurrent.FutureTask.runAndReset(
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.base/java.util.concurrent.ThreadPoolExecutor$
	at java.base/

Hello Kristian,

Thanks for reporting this.
From what we could see on our side, it seems the failure of the Automatic Analysis comes from the JS security analysis. The error you reported from the local scan seems unrelated: did you reproduce the analysis in the same conditions (same amount of memory, same nodejs version) ?

Regarding the problem of the JS security analysis, it is hard to pinpoint exactly the source of the problem without a reproducer. Would you be willing to share the yourProject/.scannerwork/ucfg2 folder of a local scan with us privately? That’s the basis used for the security analysis, and would greatly help us to investigate and understand the root of the issue.

In the meantime, you can disable the rules related to the JS Security analyzer as a temporary workaround (these are the rules: S2076, S2083, S2631, S3649, S5131, S5144, S5146, S5147, S5334, S5696, S5883, S6096, S6105, S6287, S6350). This is definitely not ideal, but would at least let you run the analysis for all the other rules.


Thanks Christophe.

I’ve tried running locally with those rules disabled in SonarCloud and I’m still seeing the isAlive was interrupted error.

If it will help to troubleshoot I can share a copy of the .scannerwork/ucfg2 folder. Do you have a secure drop link I can use?

Hello Kristian,

Thanks again for sharing the UCFGs with us, it was very helpful!
I was able to identify a bottleneck regarding memory consumption during the analysis.
A fix is underway and should be put in place in the coming days.
Thanks for your patience so far.



Hello Kristian,

We’ve deployed a fix last week that saves up quite a bit of memory. Are you still seeing an error with the Automatic Analysis on SonarCloud?


Sadly no luck with the automated analysis.

Here’s the analysis ID if it helps your team.

Last analysis failed Analysis ID “ee080fd1-e0d0-413c-8ff2-046d7daf4d41”

Do you know if there will be an update for sonar-scanner?

Hello Kristian,

Ok, thanks for letting us know.

No update on the scanner side is needed, when a new analyzer version is released, it is downloaded by the scanner from SonarCloud, so the analysis benefits from the fixes right away.

In the meantime, we’ve continued investigating some performance issues in the security analysis, and we’ve identified a bottleneck. We’re in the process of releasing it, and the new version should be deployed on SonarCloud in the next few days.

However, when looking at the logs of the analysis you’ve provided (Analysis ID “ee080fd1-e0d0-413c-8ff2-046d7daf4d41”), it seems the timeout occurred at the SCM Publisher step (after the analysis).
The new improvements done to the security analysis could be enough to make the automatic scan succeed directly, however, if the issue with the SCM Publish step persists after the fix is deployed, it might mean that using automatic analysis is not suitable for the project anymore and might require a CI-based analysis instead.

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