Hello Community!
Big news today: SonarQube Server 2026.4 is out! Check the announcement to know more about it. Let me give you a spoiler: it features architecture analysis, a feature that’s been live on SonarQube Cloud for a while and that we wanted to bring to Server too.
Lots to share on the product side this week: C/C++ users get two big betas to try out, Cross Translation Unit analysis and taint analysis on SonarQube Server, alongside the first wave of MISRA C compliance rules, and also new rules for JS/TS testing and Python/Pydantic testing.
So now, like every week, we’d like to take a moment to recognize you, the users, who help improve the ecosystem for everyone by sparking valuable discussions and providing feedback to drive continuous improvement in our products.
SonarQube MCP Server
@dan-marra-ebrs pointed out that analyze_file_list doesn’t return the rule key for reported issues, which made triage harder than it needed to be. You’re right that this was an oversight on our part, and it’s an easy enough fix that it’ll be included in the next release. MCP-568 is tracking it.
SonarQube Cloud
Scoped Organization Tokens couldn’t be used to verify an Azure DevOps Service Connection, returning an InternalServerError instead, as @FreddyGroen ran into back in January. @calle2010, @AWagen, and @Manuel.P confirmed they were hitting the same wall over the following months. Thanks for your patience while this made its way through our backlog. Scoped Organization Tokens are now supported for Azure DevOps Service Connections, so this should work as expected going forward.
@Mada_B flagged some strange project-specific behavior after a Quality Profile change: Security Hotspots reopening after being marked Safe, and issues lingering for files that no longer exist in the repository. It was a generalized problem and we were able to fix it thanks to your report!
Between roughly 15:30 and 16:52 UTC, elevated errors caused analyses to fail with UnsatisfiedDependencyException and 504 timeouts against the SonarCloud API. Thanks to @Nathaniel_Ritholtz, @patrickc, @json-o, @surecloud-jleite, @Jacob-Lowey_octa, @Edwin_Mejia, and @LorenzoBettini for reporting it so quickly (1/2). The error rates subsided once we addressed the issue on our end, and we’ve since published an RCA and improved how quickly incidents get reflected on our status page, thanks to feedback from this thread.
Scanners
@lpieprzyk noticed that the SonarQube CLI leaves behind empty .sonar/ scratch directories after every analysis, which pile up fast in agentic workflows that re-run analysis constantly. We reproduced it on our end and already have a fix in place, it’ll roll out with upcoming releases.
The sonarqube-quality-gate-action GitHub Action’s error message wasn’t very helpful when the analysis report was missing an analysisId, surfacing a bare 404 instead of the real cause, as @khalilloukhnati pointed out. SQQGGHA-12 was created to follow up on it.
@Manuel.P dug into why .NET code-style diagnostics (IDExxxx) were showing up as external issues in SonarQube Cloud despite never appearing in build output. It comes down to how Roslyn’s Sarif report is generated once EnforceCodeStyleInBuild is turned on, and we don’t currently have a way to filter which severities get imported from that report. We’ll pass the request along. Thanks @carlossus for chiming in with extra context on where Roslyn’s IDE-only diagnostics are documented!
Rules & Languages (a lot here this week!)
java:S1602 was flagging a false positive when collapsing a lambda into a method reference broke a void-returning MethodHandle.invokeExact call. @dbwiddis put together an exceptionally well-researched report, even citing a real-world regression it caused in the OSHI project. We’ve created SONARJAVA-6673 to fix this FP.
Since 2026-01-23, @MisterPi has been asking for better filtering options on java:S1192 so duplicate-string detection doesn’t flag things like repeated test fixture strings. Ticket SONARJAVA-6671 will add a parameterized exclusion list and look at other enhancements, starting with Java and expanding to other languages afterward.
csharpsquid:S3236 was reporting on caller information being hidden when nameof/CallerArgumentExpression made it redundant, as @Corniel found. We’ve created a ticket to investigate this FP.
A huge thank-you to @vxtls, who deserves a special call-out this week for three clear, reproducer-driven false positive reports in a row:
-
java:S2229was flagging missing@Transactionalself-invocation even when the call ran inside an explicitTransactionTemplatetransaction withPROPAGATION_REQUIRES_NEW. SONARJAVA-6660 was created to address it. -
java:S3077was flagging avolatilefield on an immutable record as unsafe. We’d already acknowledged this one, and you can follow the fix in SONARJAVA-4256. -
java:S2259was propagating a nullable state from a local cursor variable inside aThrowablecause-chain helper back onto the original catch parameter. SONARJAVA-6668 is tracking the fix, linked to the older related SONARJAVA-1848.
powershelldre:S8677 was raising an issue when Write-Host was used intentionally to set a pipeline variable in a script, as @milbrandt reported. We’ve created a ticket to fix this FP.
java:S9024 was flagging Mockito @InjectMocks constructor injection as something to avoid, which directly conflicted with java:S6813’s guidance to prefer constructor injection. @Yaniv_Nahoum made a valid point here: we agree java:S9024 shouldn’t be part of our default ruleset, so we’ve deactivated it from the Sonar Way profile, rolling out with our next release.
The size of eslint-plugin-sonarjs’s dependency tree came up again, with @guilhermesimoes following up with hard evidence of just how large it’s gotten. We hadn’t tackled this yet, but it’s worth another look now that there’s a lighter alternative package available, and we’ve updated JS-719 to reflect that.
@MarkLee131 provided a beautifully thorough report showing that java:S1862 misses commutative operand reversals for !=, <, >, <=, and >=, beyond the == case already fixed via an older ticket. We confirmed the false negative and created SONARJAVA-6669 to track the fix.
@MarkLee131 also spotted that java:S4201 catches a redundant null check before an instanceof in its usual form, but misses the logically identical De Morgan rewrite. We reproduced it and created SONARJAVA-6667 to fix it.
java:S8444 was flagging false positives on constructors that validate more than five parameters before calling super()/this(), as @mfroehlich pointed out. You’re right that the fixed instruction threshold doesn’t scale with argument count, and the max is configurable in the meantime if you need a workaround today. SONARJAVA-6672 was created to tune the default threshold.
Thanks again to everyone mentioned here - and to anyone we may have missed - for your ongoing contributions in making this community stronger and helping us improve Sonar products.
If you’d like to give a shout-out to someone, whether a community member or a SonarSourcer who helped you, please do so below. And if there’s someone you think we should acknowledge next week, let us know!