ALM used (GitHub)
CI system used (Azure DevOps,)
repo is mostly Typescript
Steps to reproduce - run any scan
Potential workaround - none
When viewing the dashboard it reports:
The last analysis has failed. If it keeps on failing after several attempts, please contact us on Community forum (opens in new tab) and provide the following failing analysis ID: d7033ce4-6ef2-41df-86d8-6c36ca73d62e.
Advice please?
Hey @jennymgray, welcome to the Community!
I found this error message in our logs:
java.lang.IllegalArgumentException: Line 3216 is out of range for file packages/service-user/mobile-app-translations/src/translations/en-us/enusSmartlingTranslations.ts. File has 3215 lines.
We’ve seen errors like this in the past. For example, in a particular case the file contained a raw U+2028 (LINE SEPARATOR) and a raw U+2029 (PARAGRAPH SEPARATOR) inside a single-quoted JavaScript string literal, and this was causing the problem. Maybe your case could be similar, could you please look for anything suspicious like that? In any case, I’m going to flag this for the devs to look into, and they might ask you to share the file (over private message if you don’t want to share it publicly).
As a workaround, you could try excluding the file from the test scope via .sonarcloud.properties at the repo root:
sonar.exclusions=packages/service-user/mobile-app-translations/src/translations/en-us/enusSmartlingTranslations.ts
PS: analysis d7033ce4-6ef2-41df-86d8-6c36ca73d62e is dated 2026-07-10, have you ran more recent analyses for this project? Has it been failing since then?
Its been failing since then, but my naughty team forgot to flag it to management to investigate!!
I expect that is valid content in our app, as this is our language pack file, so it is possible there would be line or paragraph separators in it. I will try the workaround, and if that is successful I can ask them to see if they can find a different way of formatting the on-screen text.
Thank you so much for replying!
Hi @jennymgray, no worries, better late than never! We’re investigating a similar case so it might be related. In any case, let us know if the team is able to spot any characters like this or at least produce a minimal reproducible version of the file which causes the crash.
What’s odd is that I tried the workaround, and it’s still saying that the last build was months ago. I need to do some digging to see if there’s another reason why that one change hasn’t made recent PRs return a proper result.