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

SonarQube Cloud
,
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