Automatic Analysis silently failing since 2026-08-28 — failing analysis ID provided

Rules and Languages New rules / language support
1

Hello,
Automatic Analysis has stopped working on our project and every retry fails.
Organization: korkut-aurelien (plan: legacy free / old_free)
Project key: KORKUT-AURELIEN_scodeller-web (private, GitHub-bound, autoscanEnabled: true)
Failing analysis ID (from the “Last analysis failed” banner): 2b538570-ed38-4c85-bd1b-88b9fc53739f
Timeline (UTC):
Up to 2026-08-28 15:22:58, analyses ran normally — last successful background task
(visible in api/ce/activity) is the main branch analysis submitted at 15:22:58, SUCCESS.
Since then, no new background task has been created at all — not for PR #283
(opened 15:45, merged 15:57), not for the main merges at 15:57 (2026-08-28) and
14:52 (2026-08-29), not for PR #284 (opened 2026-08-29 14:42). CI on GitHub is green
for all these commits.
The project page shows “Last analysis failed” with the analysis ID above.
api/ce/analysis_status returns no error (only the informational Python-version warning),
and api/ce/activity?status=FAILED shows nothing recent — the failure happens before
any Compute Engine task is created, so nothing is visible from the Web API.
Nothing changed on our side in sonar-project.properties (last touched a month ago).
The repository did grow by ~200 lines of JavaScript in the last merges, nothing unusual
(largest analyzed file: public/js/index-2.js, ~4 200 lines).
Could you check the internal logs for the failing analysis ID and tell us what is
blocking Automatic Analysis?
Thanks!

3

Hey @KORKUT-AURELIEN, welcome to the Community!

I had a look at the logs and this seems like a defect on our side: the analysis of file __tests__/util-escape.spec.js is causing a crash. I have flagged this for the dev team to check. Would you be able to share that file? They might ask you for it.

In the meantime, you could try excluding the file from the test scope via .sonarcloud.properties at the repo root:

sonar.test.exclusions=__tests__/util-escape.spec.js
4

Hi, thanks a lot for looking into this!
In the meantime we root-caused it on our side — sharing the details since they should
help your dev team.
Trigger: the file contained a raw U+2028 (LINE SEPARATOR) and a raw U+2029
(PARAGRAPH SEPARATOR) inside a single-quoted JavaScript string literal (test data
for an escaping utility). The file is 140 lines, the two characters sit on a single
line, and it had been analyzed without any problem for a month — it had not changed
since July 25. Analyses started failing on Aug 28 around 16:00 UTC with no change
on our side, which points to an analyzer update deployed that day.
Stacktrace (Automatic Analysis fails silently — no background task is created —
but running the scanner in CI surfaces it):

java.lang.IllegalArgumentException: Line 141 is out of range for file __tests__/util-escape.spec.js. File has 140 lines.
	at org.sonar.api.utils.Preconditions.checkArgument(Preconditions.java:43)
	at org.sonar.scanner.DefaultFileLinesContext.checkLineRange(DefaultFileLinesContext.java:50)
	at org.sonar.scanner.DefaultFileLinesContext.setIntValue(DefaultFileLinesContext.java:43)
	at org.sonar.plugins.javascript.analysis.AnalysisProcessor.saveMetrics(AnalysisProcessor.java:392)
	at org.sonar.plugins.javascript.analysis.AnalysisProcessor.processResponse(AnalysisProcessor.java:114)
	at org.sonar.plugins.javascript.analysis.WebSensor$AnalyzeProjectHandler.handleFileResult(WebSensor.java:454)

Our reading: when computing per-line metrics, the Node.js bridge appears to treat
U+2028/U+2029 as additional line terminators (JavaScript semantics), while the Java
side counts physical newlines only (140) — and the mismatch now crashes in
saveMetrics, which tries to store a metric for line 141.
Minimal reproduction attached (sonar-crash-repro.spec.js): the string literal
contains the raw characters (bytes E2 80 A8 / E2 80 A9), not escape sequences.
Already resolved on our side: we replaced the raw characters with their
\u2028/\u2029 escape sequences (identical string value, the test keeps its
meaning) and analysis has been green since. So we don’t need the
sonar.test.exclusions workaround — I’d rather keep the file analyzed. Happy to
share the full original file privately if the dev team needs it.

5

Hey @KORKUT-AURELIEN, that’s great, indeed running a CI analysis surfaced the same error message that I had seen in the logs.

I guess there might have been a recent change in the analyzer which introduced some sort of regression or incompatibility with these characters, so I’m still going to let the team have a look at this whenever they can, in case there’s some hardening to do on our side.

Minimal reproduction attached (sonar-crash-repro.spec.js)

I don’t see it, could you please attach it here? The team might be interested in it.

6

Here it is — attached as a zip since the forum doesn’t accept .js uploads. The archive contains sonar-crash-repro.spec.js with the raw U+2028/U+2029 bytes intact (E2 80 A8 / E2 80 A9); zipping also avoids any copy-paste normalization of those characters.

7

sonarcrashrepro.zip (714 Bytes)