SONARPY-2120 workaround: does sonar.python.coverage.reportPaths actually prevent FileProvider wa

SonarQube Server / Community Build Plugin Development
,
1

Following up on

where Guillaume Dequenne identified SONARPY-2120 and proposed
sonar.python.coverage.reportPaths with a concrete path as a workaround. We are hitting
the same race on SonarQube Server 10.6 (Developer Edition, build 92116) — but after
reviewing the source, the recommended workaround appears unable to prevent the .git/
walk. I’d like to confirm this with the team and ask what users on SonarQube < 10.8 should
actually do.

Our environment

  • SonarQube Server: 10.6 Developer Edition (build 92116), now marked “NO LONGER
    ACTIVE”
  • sonar-scanner CLI: 7.1.0.4889 (verified in trace)
  • Hosting: GitLab self-managed (Kubernetes runners on Linux/ext4)
  • Failure rate observed: ~30–40% across multiple projects with any .py files

What we’ve reproduced

Same stack trace as 124382:

```text
java.io.UncheckedIOException: java.nio.file.NoSuchFileException:
/builds//.git/.probe-
at
org.sonarsource.analyzer.commons.FileProvider.getMatchingFiles(FileProvider.java:45)
at org.sonar.plugins.python.PythonReportSensor.getReports(PythonReportSensor.java:73)
at org.sonar.plugins.python.coverage.PythonCoverageSensor.getCoverageReports(PythonCov
erageSensor.java:89)
at org.sonar.plugins.python.coverage.PythonCoverageSensor.execute(PythonCoverageSensor
.java:77)
```

Cross-project survey on our instance:

Project type sonar runs fail rate
C++ project with 3 helper .py files 28 32%
Mixed Python service A 29 31%
Mixed Python service B 33 18%
100% Java project (no .py) 34 3%

The 100% Java project (which never activates PythonCoverageSensor via
@onlyOnLanguage(Python.KEY)) is our control sample, strongly suggesting Python sensor
activation is the trigger.

Why we doubt the recommended workaround

Reading FileProvider.java from sonar-analyzer-commons:

Source: sonar-analyzer-commons/commons/src/main at master · SonarSource/sonar-analyzer-commons · GitHub
/java/org/sonarsource/analyzer/commons/FileProvider.java

```java
public List getMatchingFiles() {
try (var walk = Files.walk(baseDir)) { // unconditional walk
return walk
.filter(p → !Files.isDirectory(p)
&& pattern.match(toUnixString(baseDir.relativize(p))))
.map(Path::toFile)
.collect(Collectors.toList());
} catch (IOException e) {
throw new IllegalStateException(“Failed to get matching files.”, e);
}
}
```

Files.walk(baseDir) is invoked unconditionally — the pattern is only applied as a
post-filter. There is no short-circuit for literal (non-glob) paths. The walker therefore
enters .git/ regardless of whether sonar.python.coverage.reportPaths is set to a
concrete path or left at the default glob.

This contradicts Guillaume’s statement in 124382 that setting the property would “ensure
that it doesn’t search in the .git folder.” Could you clarify which is correct?

Specific questions

  1. Is the FileProvider source above complete? Is there a short-circuit path I’m
    missing — perhaps in a different version of sonar-analyzer-commons, or upstream of
    FileProvider.getMatchingFiles()?

  2. If the walk is genuinely unconditional, then the recommended workaround in 124382
    is misleading. What is the actually effective workaround for users on SonarQube < 10.8
    (sonar-python < 4.23 without the SONARPY-2120 graceful-failure fix)?

  3. Does sonar.scm.disabled=true fully prevent JGit initialization (and therefore the
    .probe-* race), or are there other sensors (e.g. TextAndSecretsSensor) that still
    open a JGit Repository and trigger FS.FileStoreAttributes?

  4. Pre-seeding ~/.config/jgit/config with measured timestampResolution /
    minRacyThreshold skips the probe entirely (per JGit upstream behavior). Is this an
    officially supported workaround for SonarScanner CLI users?

  5. For projects with only a few .py files, would setting
    sonar.python.file.suffixes= (empty) — effectively disabling Python language detection —
    be acceptable? This sidesteps the race by preventing all Python sensors from activating,
    at the cost of losing analysis on the (irrelevant) Python helpers.

  6. Beyond SONARPY-2120, is there a sibling ticket for the underlying FileProvider
    design issue (walks unconditionally for any pattern, not just ** globs)? This affects
    multiple sensors — Java classpath in
    Sonar-Job in gitlab pipeline somestime crash with java.nio.file.NoSuchFileException
    Python coverage here, potentially others.

Thanks for your help — happy to provide more traces or run experiments if it would help
triage.

2

Hey @dongjie, SonarQube 10.6 is severely outdated, I think you should consider updating to a modern version where this is fixed rather than trying to find a workaround that will work in your version.