Server 2026.4 (Enterprise) - JavaScript/TypeScript/CSS sensor logs non-fatal parse issue a ERROR

SonarQube Server / Community Build
,
1

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 2022 and 2025, 16GB RAM per VM

Summary:

The JavaScript/TypeScript/CSS analysis [javascript] sensor completes successfully (build passes, analysis is marked green in SonarQube), but it is logging a file parsing issue as an ERROR with an ##[error] annotation rather than a WARN. This means every affected build now shows as having pipeline errors in Azure DevOps, even though nothing has actually failed. In the past this same situation (a file the parser can’t fully handle) surfaced only as a WARN, not a build-level error.

Log output:

INFO: Sensor JavaScript/TypeScript/CSS analysis [javascript]
INFO: Detected os: ...
INFO: Using embedded Node.js runtime.
INFO: Using Node.js executable: 'C:\Users\<user>\.sonar\js\node-runtime\node.exe'.
INFO: Memory configuration: OS (16382 MB), Node.js (4288 MB).
INFO: gRPC analyze-project server listening on 127.0.0.1:56837
INFO: Plugin version: [13.3.0.43633]
##[error]ERROR: Error: Unknown word -->
ERROR: Error: Unknown word -->
##[error]ERROR:     at e.parsingError (D:\<agent-path>\.sonarqube\out\.sonar\.sonartmp\bridge-bundle\package\bin\server.cjs:1777:3109)
ERROR:     at dJA (D:\<agent-path>\.sonarqube\out\.sonar\.sonartmp\bridge-bundle\package\bin\server.cjs:2188:746)
[... stack trace repeated twice ...]
WARN: Failed to parse file [src/code/<project>/offline_messages/app_offline.htm] at line 60: Unknown word -->
INFO: Found 0 tsconfig.json file(s): []
INFO: 8 source files to be analyzed

Key observation:

The actual root cause is logged correctly further down, as a WARN:

WARN: Failed to parse file [src/code/AmberWebUI/offline_messages/app_offline.htm] at line 60: Unknown word -->

This is an .htm file (not JS/TS/CSS) that the JS parser evidently attempts to touch and can’t fully parse. The sensor handles this gracefully, it doesn’t fail the build, still finds 8 source files to be analyzed, and completes normally. However, before that WARN line appears, the same underlying event is also emitted twice as ERROR (with ##[error] annotations), which is what Azure DevOps picks up and surfaces as pipeline errors on an otherwise successful build.

What we’ve observed:

  1. The build itself does not fail, SonarQube analysis completes and is reported as passing/green.
  2. The same parsing situation for non-JS/TS/CSS files has historically only produced a WARN, not an ERROR.
  3. The ERROR block appears to be a duplicate/higher-severity echo of the same single parsing event that is separately logged correctly as WARN a few lines later.
  4. This is now happening across all of our AZDO build pipelines, so every affected build shows as containing errors in the Azure DevOps UI, even though the analysis has succeeded.

Questions:

  1. Is this a known change in how the JS/TS/CSS sensor reports file parsing issues, has the severity of this specific event changed from WARN to ERROR in a recent plugin version?
  2. Should a non-fatal parsing issue on a file the sensor still successfully skips (analysis completes, build passes) be logged as ERROR at all, given it doesn’t reflect an actual failure?
  3. Is there a way to configure or exclude this so that non-JS/TS/CSS files (like .htm) aren’t parsed by this sensor at all, to avoid this false-error noise in our pipelines?

Happy to provide the full debug log and pipeline configuration if this is useful.

This issue currently means that some builds are reporting errors, that never use to be errors but also report as warnings. (But builds are still working)

Thanks

2

Hi @Luke_M,

Thanks for the detailed report of the issue you’re experiencing.

What you’re seeing appears to be a two-part situation:

The underlying parse event is non-fatal. The JS/TS/CSS sensor is picking up app_offline.htm, attempting to parse it as JavaScript/CSS, and failing when it encounters --> (an HTML comment close tag), which isn’t valid JS/CSS syntax. The sensor skips the file and continues, which is why your analysis completes successfully and shows green.

It looks like the logging severity is the problem. In the current version, the raw Node.js exception from the bridge’s internal parser is being emitted at ERROR level before the sensor’s error handler converts it to the expected WARN: Failed to parse file... message. This produces the confusing duplication of the same event logged twice at two different levels. And additionally, as you mentioned, Azure DevOps’ pipeline runner annotates any ERROR: prefixed line with ##[error], making a passing build look like it has failures.

Here’s a workaround you can consider. Exclude the file (or all .htm files) from analysis by adding this to your scanner parameters or sonar-project.properties:

# Exclude just the offline page
sonar.exclusions=**/app_offline.htm

# Or, if other .htm files trigger the same issue
sonar.exclusions=**/*.htm

This will prevent the JS sensor from attempting to parse the file at all, which eliminates both the WARN and the ERROR output. I’ll flag this internally for further investigation.

In the meantime, the exclusion above should resolve the pipeline noise immediately. Let me know if you run into any issues applying it.

Best regards,

Stevan

6

Hello,

we created a ticket to fix this.

Thanks for the report!
Victor

8

No worries thanks @victor.diez @stevan.vanderwerf :+1: