SonarJS bridge server 300s startup timeout on self-hosted Bitbucket runner aborts entire analysis

SonarQube Cloud
,
1

SonarJS bridge server 300s startup timeout on self-hosted Bitbucket runner aborts entire analysis (also fails with all JS/TS/CSS excluded)

Versions and env
Analysis: sonarsource/sonarcloud-scan:4.1.0 Bitbucket pipe. SonarScanner CLI 7.1.0.4889, engine Java 21.0.9.

  • JavaScript/TypeScript analyzer plugin: 13.0.0.42526
  • Bitbucket Pipelines self-hosted runner (Linux, Docker), runner 5.7.0.
  • Host: AWS m5.xlarge — 16 GB RAM, 4 vCPU, RHEL 8 (kernel 4.18.0-553 el8_10).
  • Analyzer reports: Memory configuration: OS (15465 MB), Node.js (4288 MB) (embedded Node).

What we’re trying to do

Run our normal PR/branch analysis (mostly a large PHP project, plus legacy JS). This used to
complete fully (PHP + JS) in ~20–30 min. Recently the JS step began failing and it aborts the
whole scan.

Error observed

INFO  Sensor JavaScript/TypeScript/CSS analysis [javascript]
INFO  Using embedded Node.js runtime.
INFO  Memory configuration: OS (15465 MB), Node.js (4288 MB).
   (~5 min of silence)
ERROR Failed to start the bridge server (300s timeout)
      org.sonar.plugins.javascript.bridge.BridgeServerImpl.startServer(BridgeServerImpl.java:224)
      org.sonar.plugins.javascript.bridge.BridgeServerImpl.startServerLazily(BridgeServerImpl.java:435)
      org.sonar.plugins.javascript.analysis.WebSensor.execute(WebSensor.java:177)
ERROR Error during SonarScanner Engine execution
      java.lang.IllegalStateException: Error while running Node.js. …
INFO  EXECUTION FAILURE

Because the scanner then exits with code 3, the entire analysis is aborted — our PHP
analysis, which finished successfully just before, is never submitted.
(On some runs we do see gRPC analyze-project server listening on 127.0.0.1:<port> before it
still times out; on others nothing is logged after the memory line.)

What we already ruled out

  1. Not memory: 16 GB host, Node auto-sized to 4288 MB, PHP security sensor peaks ~2.6 GB and
    completes. (On a previous 8 GB host the step was OOM-killed; 16 GB fixed the OOM and now
    everything completes except this bridge startup.)
  2. Independent of the analyzed files: we excluded all JS/TS/CSS via sonar.exclusions
    (**/*.js,**/*.cjs,**/*.mjs,**/*.jsx,**/*.ts,**/*.tsx,**/*.vue,**/*.css,**/*.scss,**/*.less).
    Confirmed effective (“9 languages detected” vs 12; js/ts/css profiles no longer load). Yet
    the WebSensor still starts the bridge and still times out    , aborting the scan.
  3. Intermittent: ~1 success out of 5 runs on the 16 GB host.
  4. sonar.javascript.detectBundles=false is set (it fixed a separate ~56 min preprocessing
    slowness on our large legacy JS surface); no effect on the bridge startup.

Questions

  1. Known bridge-startup regression in analyzer 13.0.0.42526 on RHEL 8?
  2. Is the 300s bridge-startup timeout configurable?
  3. Why does the WebSensor start the bridge even when all JS/TS/CSS files are excluded, and how
    can we skip the JS/TS/CSS sensor so its failure doesn’t abort the PHP submission?
  4. Is sonar.nodejs.executable (system Node) the recommended workaround, and which Node
    version for 13.0.0.42526?
  5. Can the JS bridge failure be made non-fatal so the rest of the analysis is still submitted?

Debug logs: I can attach a full sonar.verbose=true run on request.

2

Hi @odasilva,

Welcome to the Community! The specific log signature Shutting down gRPC analyze-project server: lease acquisition timeout followed by The worker thread exited with code 1 is a distinct pattern from the generic bridge timeout, and it’s been reported recently in this thread with the same symptom. It may be worth checking that thread as context.

Why does the bridge start despite JS exclusions? sonar.exclusions scoped to JS/TS/CSS files prevents those files from being analyzed, but the WebSensor initializes the bridge regardless because it also handles HTML and other web assets. The bridge startup is not currently gated on whether any JS/TS/CSS files are present in the analysis scope.

Is the 300s timeout configurable? Yes, via sonar.javascript.node.timeout (value in seconds). This won’t fix the underlying worker crash but may help in environments where startup is genuinely slow.

Is sonar.nodejs.executable recommended? Yes, if the embedded Node.js runtime is unstable on your RHEL 8 / kernel 4.18 host, pointing to a system-installed Node.js 18 LTS or 20 LTS via -Dsonar.nodejs.executable=/path/to/node is a supported workaround and worth trying.

Can bridge failure be made non-fatal? Not currently. The bridge failure throws an exception that aborts the entire scan.

Immediate things to try:

  1. Set -Dsonar.nodejs.executable=/usr/bin/node (or wherever your system Node is) with Node 18 or 20 LTS
  2. Add -Dsonar.javascript.node.debugMemory=true and -Dsonar.verbose=true to the next run and share the full output, particularly anything between Starting server and The worker thread exited with code 1
  3. Try increasing sonar.javascript.node.timeout 60000 or 120000

Hope that helps.

Cheers,

Stevan