Environment:
- SonarQube Server:
2026.4 (Enterprise)- Recently Upgraded issue has only occurred after this upgrade. - Deployment: self-hosted
- CI: Azure DevOps Server (on-prem) - Latest, Classic pipeline
- AZDO SonarQube extension:
8.2.3(latest) - Scanner:
SonarScanner for .NET 11.2.1 - SonarJS plugin:
13.3.0.43633 - Build agents: self-hosted, mixture of Windows Server
2022and2025, 16GB RAM per VM
Summary:
The JavaScript/TypeScript/CSS analysis [javascript] sensor crashes with a Node.js heap out of memory error, roughly 25 to 35 seconds after the sensor’s bridge process starts. This only affects a small subset of our projects, the majority of our builds analyse successfully with the same scanner, plugin, and agent pool. For the affected projects, the crash is fully reproducible and has happened on every run we’ve tried, across multiple separate builds. Extensive debugging on the affected projects (see below) has not surfaced anything that explains why they specifically are affected.
Typical log pattern:
Sensor JavaScript/TypeScript/CSS analysis [javascript]
Detected os: ...
Configured Node.js --max-old-space-size=XXXX.
Using embedded Node.js runtime.
Using Node.js executable: 'C:\Users\<user>\.sonar\js\node-runtime\node.exe'.
Memory configuration: OS (16382 MB), Node.js (XXXX MB)
gRPC analyze-project server listening on 127.0.0.1:62749
Plugin version: [13.3.0.43633]
[25-35 seconds of no output]
ERROR: The analysis will stop due to the Node.js process running out of memory (heap size limit XXXX MB)
ERROR: You can see how Node.js heap usage evolves during analysis with "sonar.javascript.node.debugMemory=true"
ERROR: Try setting "sonar.javascript.node.maxspace" to a higher value to increase Node.js heap size limit
ERROR: If the problem persists, please report the issue at https://community.sonarsource.com
ERROR: You can see how Node.js heap usage evolves during analysis with "sonar.javascript.node.debugMemory=true"
ERROR: Try setting "sonar.javascript.node.maxspace" to a higher value to increase Node.js heap size limit
ERROR: If the problem persists, please report the issue at https://community.sonarsource.com
ERROR: Failed to get response from analysis
... <Sumamrised but I have full debug outputs too>
What we’ve tested and ruled out:
- Memory ceiling. Tried
sonar.javascript.node.maxspaceat default (4096/4288),8192, and8384MB. Crashes identically at every value, just against a higher ceiling. - File content. One of our affected repositories has almost no real JS/TS/CSS content (around 8KB across 2 files, no
package.json,tsconfig.json, ornode_modulesanywhere). We excluded everything JS/CSS related viasonar.exclusionsand confirmed via the indexing log that the exclusion was applied. The sensor still ran and crashed identically. - Host contention. Confirmed that the build agent VM was completely idle (no other builds running) during at least one failing run.
- Gradual memory growth. With
sonar.javascript.node.debugMemory=trueenabled, we got zero heap usage samples logged before the crash. This points to a large or sudden allocation issue rather than a slow leak from processing many files. - Scanner/plugin version. Confirmed stable across all runs at
SonarScanner for .NET 11.2.1and plugin13.3.0.43633. - Isolation to specific projects. The same scanner, plugin version, and build agent pool successfully analyse the majority of our other projects without issue. Whatever is triggering this is specific to a small subset of projects, but we have not been able to identify what differs about them.
Additional note:
From testing: the crash consistently lands around 25 to 35 seconds after the bridge starts, which is fast and repeatable enough. That it may point to a small number of large or complex files overwhelming the TypeScript compiler’s shared program, rather than a large codebase gradually accumulating memory. We mention this as a possible mechanism, not a confirmed cause, since our zero-content repository crashes with the same timing and signature despite having no such files.
We’ve followed all the guidance available in the SonarQube documentation for diagnosing this (maxspace, debugMemory, exclusions), but none of it has surfaced anything useful. In particular, sonar.javascript.node.debugMemory=true is supposed to log periodic heap usage samples so you can see memory climbing, but in every failing run we get zero samples before the crash. The process dies before it ever reaches the point of emitting that output, so we have no visibility into what’s actually being allocated.
Questions:
- Why does the sensor spawn the Node bridge and attempt analysis even when
sonar.exclusionsremoves every JS/TS/CSS-matching file from the project? - What happens during bridge/worker start-up, before any per-file diagnostic log line is emitted, that could account for a large or instant allocation independent of file content?
- Is there a known issue in plugin
13.3.0.43633related to worker thread heap sizing, TypeScript program construction, or bridge start-up on Windows self-hosted agents? - Is there anything specific to a project (repo size, module count, language mix, etc.) that could cause this sensor to behave differently, given that most of our projects analyse successfully with identical scanner/plugin/agent configuration?
Happy to send full pipeline scanner logs (including a debugMemory-enabled run) and our pipeline configuration if that would help diagnose this.
This issue currently means we have a few projects/builds we can no longer scan in a pipeline as no matter what we do/try we can not stop it crashing/eating memory.
Thanks