[SonarJS][TypeScript] Bridge server unresponsive blocks entire analysis

SonarQube Server / Community Build
, , ,
1

Must-share information

Which versions are you using (SonarQube Server / Community Build, Scanner, Plugin, and any relevant extension):

  • SonarQube Server: v2025.4.1 (build 111832), Developer Edition (zip install)

  • Sonar Maven Scanner: org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121

  • JavaScript/TypeScript analyzer (SonarJS): bundled with SonarQube v2025.4.1

  • Node.js runtime: v22.11.0 (Jenkins agent)

  • Jenkins: 2.501

  • Jenkins NodeJS plugin: 1.6.4

  • Agent VM: 8 CPU, 64 GB RAM, Ubuntu 24.04

How is SonarQube deployed: zip, Docker, Helm

  • Deployed via zip distribution on a dedicated VM.

  • Jenkins runs on a separate VM and executes the scanner jobs.

What are you trying to achieve
Analyze a large TypeScript/React codebase (~3,500 .ts/.tsx files, ~350K LOC) reliably.
Goal: have the analysis complete even if a few files are very heavy or problematic.

What have you tried so far to achieve this

  • Created a narrowed tsconfig.sonar.json to reduce program size.

  • Increased Node heap:

    -Dsonar.javascript.node.maxspace=16384
-Dsonar.javascript.node.maxspace=32768
-Dsonar.javascript.node.debugMemory=true

  • Increased scanner/network timeouts:

    -Dsonar.scanner.socketTimeout=600
-Dsonar.scanner.responseTimeout=600
-Dhttp.socket.timeout=1000000
-Dsonar.qualitygate.timeout=3600

  • Enabled debug logging:

    -X -Dsonar.verbose=true -Dsonar.log.level=DEBUG

  • Monitored memory in logs, example:

    Using Node.js heap limit: ~16384 MB
JS/TS analyzer memory: used=..., heapUsed=..., rss=...

  • In older versions, problematic files (e.g. DQScoreCalculation.tsx) produced errors like:

    Failed to analyze file [src/.../DQScoreCalculation.tsx] from TypeScript: Map maximum size exceeded
Rule: "no-misused-promises"

    …but analysis continued with the rest of the files.

  • In the current version, the analyzer stalls on such files and eventually ends with:

    java.net.http.HttpTimeoutException: request timed out
The bridge server is unresponsive

    This causes the entire analysis to fail.

Logs (text only, formatted)

Excerpt from old run (analysis continued despite errors):

[ERROR] Failed to analyze file [src/core/DQDashBoards/components/DQScoreCalculation.tsx] from TypeScript: Map maximum size exceeded
Occurred while linting ...: Rule: "no-misused-promises"
[ERROR] Failed to analyze file [src/components/ChartLegend/ChartLegend.tsx] from TypeScript: Map maximum size exceeded
Rule: "arguments-order"

Excerpt from current run (analysis stalls, then fails):

[INFO] 142/4185 files analyzed, current file: src/core/DQDashBoards/components/DQScoreCalculation.tsx
[INFO] 142/4185 files analyzed, current file: src/core/DQDashBoards/components/DQScoreCalculation.tsx
... (repeats for minutes) ...
[ERROR] java.net.http.HttpTimeoutException: request timed out
[ERROR] The bridge server is unresponsive

Question

  • In older versions, when a file triggered a linting exception, the analyzer logged the error but continued with the rest of the project.
    In current version, the entire analysis fails if one file stalls.
    Is there a way to configure Sonar so that failing files are skipped but analysis continues (fail-fast on file, not on whole analysis)?

  • Is there a way to identify which rules are consuming excessive time or causing the “Map maximum size exceeded” errors (e.g. no-misused-promises), so that we can tune our Quality Profile?

  • What is the recommended workaround for large TypeScript projects where a single file can block the bridge process?

3

Hi @Akhilesh_Jinkala,

I’m sorry you are experiencing issues. What we usually recommend is to break-up your single tsconfig.json file into multiple smaller projects and provide these to the analyzer. Please see the explanation in the documentation here - JavaScript, TypeScript, CSS | SonarQube Server Documentation

However, if it is possible to reproduce this behavior with just a single file, then it might mean that it’s a single rule having issues. In that case, it’d be great if you could see if you can provide a reproducer.

Worst case scenario, you can exclude specific files from an analysis - Excluding files based on path-matching patterns | SonarQube Server Documentation

Kind regards,

Michal