Analysis cache - some scanners require parsing

SonarQube Server / Community Build
,
1

Hello,
We are trying to speed up the analysis on Pull Requests and hoped that the analysis cache would help, however analysis times seem to be identical compared to non-branch analysis.
According to the logs some checks seem to require parsing of the .java sources:

[2025-12-01T07:09:10.327Z] [INFO] The Java analyzer is running in a context where unchanged files can be skipped. Full analysis is performed for changed files, optimized analysis for unchanged files.
[2025-12-01T07:09:10.327Z] [DEBUG] 'com/company/Whatever.java' generated metadata with charset 'UTF-8'
[2025-12-01T07:09:10.327Z] [DEBUG] Scanners that require parsing of com/company/Whatever.java: [com.sonarsource.dbd.frontend.java.rules.ClassCastCheck@52f242d0, com.sonarsource.dbd.frontend.java.rules.ExceptionReachabilityCheck@52ba6912, com.sonarsource.dbd.frontend.java.rules.InfiniteRecursionCheck@d0f11ce, com.sonarsource.dbd.frontend.java.rules.UnsupportedMethodCheck@6d9f2787, com.sonarsource.dbd.frontend.java.rules.CollectionModifiedDuringIterationCheck@121e5557, com.sonarsource.dbd.frontend.java.rules.JavaIndexErrorCheck@27ce8d44]
[2025-12-01T07:09:10.328Z] [DEBUG] 'com/company/Whatever.java' generated metadata with charset 'UTF-8'
[2025-12-01T07:09:10.329Z] [DEBUG] Scanners that require parsing of com/company/Whatever.java: [com.sonarsource.dbd.frontend.java.rules.ClassCastCheck@52f242d0, com.sonarsource.dbd.frontend.java.rules.ExceptionReachabilityCheck@52ba6912, com.sonarsource.dbd.frontend.java.rules.InfiniteRecursionCheck@d0f11ce, com.sonarsource.dbd.frontend.java.rules.UnsupportedMethodCheck@6d9f2787, com.sonarsource.dbd.frontend.java.rules.CollectionModifiedDuringIterationCheck@121e5557, com.sonarsource.dbd.frontend.java.rules.JavaIndexErrorCheck@27ce8d44]
[2025-12-01T07:09:10.329Z] [DEBUG] 'com/company/Whatever.java' generated metadata with charset 'UTF-8'
[2025-12-01T07:09:10.330Z] [DEBUG] No cached UCFGs found, file will need to be parsed.
[2025-12-01T07:09:10.330Z] [DEBUG] Scanners that require parsing of com/company/Whatever.java: [com.sonarsource.dbd.frontend.java.rules.ClassCastCheck@52f242d0, com.sonarsource.dbd.frontend.java.rules.ExceptionReachabilityCheck@52ba6912, com.sonarsource.dbd.frontend.java.rules.InfiniteRecursionCheck@d0f11ce, com.sonarsource.dbd.frontend.java.rules.UnsupportedMethodCheck@6d9f2787, com.sonarsource.dbd.frontend.java.rules.CollectionModifiedDuringIterationCheck@121e5557, com.sonarsource.dbd.frontend.java.rules.JavaIndexErrorCheck@27ce8d44, com.sonar.security.frontend.java.rules.ReflectedXssCheck@365d5b7e, com.sonar.security.frontend.java.rules.SQLInjectionCheck@4a736bcb, com.sonar.security.frontend.java.rules.OSCommandInjectionCheck@3a005d37, com.sonar.security.frontend.java.rules.OSArgumentInjectionCheck@7107f4c0, com.sonar.security.frontend.java.rules.XPathInjectionCheck@6a9fb8c, com.sonar.security.frontend.java.rules.LDAPInjectionCheck@4956f632, com.sonar.security.frontend.java.rules.RegularExpressionDoSCheck@4ab148cb, com.sonar.security.frontend.java.rules.FilePathInjectionCheck@7ac79576, com.sonar.security.frontend.java.rules.DeserializationCheck@5359e941, com.sonar.security.frontend.java.rules.ServerSideRequestCheck@7dc54847, com.sonar.security.frontend.java.rules.A@2650356, com.sonar.security.frontend.java.rules.LoggingInjectionCheck@6b7c548f, com.sonar.security.frontend.java.rules.HttpRedirectionCheck@40871bbb, com.sonar.security.frontend.java.rules.DynamicCodeExecutionCheck@5aa2d60d, com.sonar.security.frontend.java.rules.ZipSlipCheck@555ee2b0, com.sonar.security.frontend.java.rules.SessionFixationCheck@45e14a9, com.sonar.security.frontend.java.rules.OSArgumentConstructionCheck@3479b0df, com.sonar.security.frontend.java.rules.IntentRedirectionCheck@4252f4c1, com.sonar.security.frontend.java.rules.ReflectionInjectionCheck@54adf3f0, com.sonar.security.frontend.java.rules.NoSQLInjectionCheck@3b584cdb, com.sonar.security.frontend.java.rules.XMLOperationsCheck@8c04f97, com.sonar.security.frontend.java.rules.JSONOperationsCheck@5fac6e2d, com.sonar.security.frontend.java.rules.ThreadSuspensionDoSCheck@1da38f48, com.sonar.security.frontend.java.rules.FileSystemOracleCheck@1b4197f8, com.sonar.security.frontend.java.rules.OSEnvironmentVariablesCheck@571f2823, com.sonar.security.frontend.java.rules.ApiTraversalCheck@6425245b, com.sonar.security.frontend.java.rules.PromptInjectionCheck@707704e6, com.sonar.security.frontend.java.rules.CrossApplicationAttackCheck@7692a9ae, com.sonar.security.frontend.java.rules.SensitiveInformationDisclosureCheck@f83d564]

Is it expected that some checks (such as com.sonarsource.dbd.frontend.java.rules.ClassCastCheck) do not allow cached analysis data?

This happens on sonarqube Enterprise Edition v2025.5 (113872) and we’re migrating from Community Build v25.11.0.114957

1 Like
2

Hey @gtoison ,

We have the same issue, we posted about it here. But we never found a solution. The last thing we tried was to disable all the dbd rules but never managed to do it.

Hope this post will be successfull

1 Like
3

Hi,

Can you add -Dsonar.verbose=true to your analysis command and post the analysis log, please?

The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.

This guide will help you find them.

 
Thx,
Ann

4

Hi Ann,
I have shared the full verbose log privately with Sylvain Combe,
Guillaume

5

Hi,

Then I’ll let him pursue this.

 
Ann

6

Hello @gtoison

Would you be willing to share the state of the investigations ?

7

The feedback we have received so far is that the cache hit ratio is at ~10% which is well under the expectation for a PR where only very few files are modified.

8

Thank you @gtoison. We do have the same issue, albeit with a slightly better cache ratio. For a PR with exactly 0 Java file changed, we get an overall Cache Hit Ratio of 36% (3000/8400).

If interested @Sylvain_Combe , we can also provide logs for the investigations.

11

Hey @gtoison,

I found something about the build path to make the cache work. Maybe it could help you : Cache hit very low for PR on CI