After upgrading to SonarQube Community Build v26.6.0.123539, Jenkins analysis on our Windows agent fails because the JS/HTML analyzer’s local gRPC bridge starts and then exits with
“lease acquisition timeout”.
Versions
SonarQube: Community Build v26.6.0.123539
Scanner: Jenkins Sonar scanner tool using sonar-scanner -X
JavaScript plugin / analyzer: 12.5.0.41048
Java: JDK 17.0.11
Node.js:
Sonar embedded Node runtime
log shows Node.js v24.11.0
Build agent OS: Windows Server 2022
Deployment
zip install / SonarService installed as Windows service.
What we are trying to achieve
We are trying to run SonarQube analysis from Jenkins on a Windows build agent after upgrading SonarQube Community Build.
What we have tried so far
Tried different Node versions
Tried both Sonar managed embedded Node and host provided Node
Increased Node memory with -Dsonar.javascript.node.maxspace=
Enabled debug logging with:
-X
-Dsonar.verbose=true
-Dsonar.javascript.node.debugMemory=true
Confirmed the embedded Node process starts and binds to 127.0.0.1
Jenkins scanner invocation
bat """
"${scannerHome}/bin/sonar-scanner" ^
-X ^
-Dsonar.verbose=true ^
"""
## Relevant log output
```text
INFO Deploy location <user-profile>\.sonar\js\node-runtime, targetRuntime: <user-profile>\.sonar\js\node-runtime\node.exe, version: <user-profile>\.sonar\js\node-runtime\version.txt
DEBUG Currently installed Node.js version: v24.11.0. Available version in analyzer: v24.11.0
DEBUG Skipping node deploy. Deployed node has latest version.
DEBUG Launching command <user-profile>\.sonar\js\node-runtime\node.exe -v
DEBUG Deployed node version v24.11.0
DEBUG Starting server
DEBUG Creating Node.js process to start the bridge server on port 0
INFO Configured Node.js --max-old-space-size=16384.
INFO Using embedded Node.js runtime.
INFO Using Node.js executable: '<user-profile>\.sonar\js\node-runtime\node.exe'.
DEBUG Checking Node.js version
DEBUG Launching command <user-profile>\.sonar\js\node-runtime\node.exe -v
DEBUG Using Node.js v24.11.0.
DEBUG Launching command <user-profile>\.sonar\js\node-runtime\node.exe --max-old-space-size=16384 <workspace>\.scannerwork\.sonartmp\bridge-bundle\package\bin\server.cjs 0 127.0.0.1 true
15000
DEBUG The worker thread is running
INFO Memory configuration: OS (130829 MB), Node.js (16576 MB).
INFO gRPC analyze-project server listening on 127.0.0.1:54840
DEBUG Major GC event
DEBUG {"name":"gc","entryType":"gc","startTime":9985.6784,"duration":25.635400000028312,"detail":{"kind":4,"flags":32}}
DEBUG
{"total_heap_size":168271872,"total_heap_size_executable":3162112,"total_physical_size":168271872,"total_available_size":17217277440,"used_heap_size":164668616,"heap_size_limit":17381195
776,"malloced_memory":2129968,"peak_malloced_memory":116841952,"does_zap_garbage":0,"number_of_native_contexts":2,"number_of_detached_contexts":0,"total_global_handles_size":12360,"used_
global_handles_size":3968,"external_memory":3242018}
DEBUG Shutting down gRPC analyze-project server: lease acquisition timeout
DEBUG The worker thread exited with code 1
DEBUG The worker thread exited with code 1
ERROR Failed to start the bridge server (300s timeout)
org.sonar.plugins.javascript.nodejs.NodeCommandException: Failed to start the bridge server (300s timeout)
at org.sonar.plugins.javascript.bridge.BridgeServerImpl.startServer(BridgeServerImpl.java:230)
at org.sonar.plugins.javascript.bridge.BridgeServerImpl.startServerLazily(BridgeServerImpl.java:435)
at org.sonar.plugins.javascript.analysis.WebSensor.execute(WebSensor.java:155)
...
ERROR Error during SonarScanner Engine execution
java.lang.IllegalStateException: Error while running Node.js. A supported version of Node.js is required for running the analysis of JS/TS files.
Caused by: org.sonar.plugins.javascript.nodejs.NodeCommandException: Failed to start the bridge server (300s timeout)
Hey @j.odonnell, welcome to the Community! We’ve seen this error in the past when certain network/firewall rules were blocking localhost calls (from the Java process running the scanner to the Node server started by the scanner). Is it possible that the agent host (the Windows machine) is applying such rules? You could try to reproduce this by running a dummy node server on the machine and then trying to invoke it with an HTTP client (curl, Invoke-WebRequest…).
Hey @andres! Thank you for the suggestion. I have tried reproducing the issue with a simple dummy Node server listening on 127.0.0.1 and was able to connect to it successfully with both curl and PowerShell, so it doesn’t appear to be a general localhost/network/firewall issue.
What I have noticed is that the problem only occurs when Java analysis is included in our Sonar scan. If I exclude any Java files, the JS/TS analyser starts and completes without any issue. When including Java, the Java analysis itself completes but immediately afterwards, when Sonar starts the JS/TS bridge, it reports that the gRPC server is listening and then exactly 15 seconds later exits with the lease acquisition timeout.
The confusing part is that the JS/TS analyzer isn’t actually analysing any Java code. My suspicion is that including Java analysis increases the overall workload/scope of the scan, and that is somehow exposing an issue in the new gRPC-based bridge. This same project analysed successfully before upgrading to Community Build 26.6, so the change in the JS/TS bridge architecture from web sockets to gRPC-based communication is something which stood out to me.
Thanks for sharing all these details, indeed it sounds suspicious that it started to happen after the upgrade… One thing I’d like to clarify is, what do you mean exactly by “when Java analysis is included”? What configuration are you using to include or exclude it?
I’m going to flag this thread for the devs to have a look at. Are you willing to share debug-level logs from both the run where it succeeds and the run where it fails? it’s likely that the devs will want to see those.
Thanks Andrés. By “excluding Java”, I mean setting sonar.global.exclusions=**/*.java in the global Analysis Scope settings. With that exclusion in place, the scan only analyses the remaining file types (JS, CSS, etc.), and the JS/TS bridge starts and the analysis completes successfully. As soon as I remove the **/*.java exclusion and Java files are included in the analysis again, the JS/TS bridge starts, listens on localhost, and then exits with the lease acquisition timeout.
Yes, I’m happy to provide debug logs from both the successful and failing runs. Please let me know the best way to send them
Hi @victor.diez . I’ve attached the debug logs from both Jenkins runs.
GOOD – **/.java is excluded via sonar.global.exclusions, so the scan analyses the remaining file types and completes successfully.
BAD – the **/.java exclusion is removed, so Java is included in the analysis. The Java analysis completes, but then when the JS/TS bridge starts it reports that it is listening and then exits with lease acquisition timeout.
I’ve had to obfuscate some project details/paths etc. Also trimmed some unrelated sections to keep the logs to a reasonable size, but I’ve left the relevant parts intact.
Please let me know if you need any additional information.
@victor.diez@andres thank you for your assistance. It is very much appreciated! Adding this property to my sonar-scanner step was the fix. Sonar analysis is now completing successfully with no exclusions.
