SonarSource/sonarqube · error · IllegalStateException

Could not check the size of the report temp file

Error message

Could not check the size of the report temp file

What it means

ReportSubmitter.getSourceSize reads the size of the temp report file via Files.size to decide how to split it. An IOException here (file vanished between write and stat, I/O error) is wrapped in this IllegalStateException. It is an internal bookkeeping step of report submission and almost always signals storage trouble.

Source

Thrown at server/sonar-webserver-webapi/src/main/java/org/sonar/server/ce/queue/ReportSubmitter.java:285

  long getReportMaxSizeBytes() {
    return configuration.getInt(REPORT_PART_MAX_SIZE_MBYTES)
      .map(mBytes -> mBytes * 1024 * 1024)
      .orElse(450 * 1024 * 1024);
  }

  private static void writeReportToTempFile(InputStream reportInput, File tempFile) {
    try {
      Files.copy(reportInput, tempFile.toPath(), StandardCopyOption.REPLACE_EXISTING);
    } catch (IOException e) {
      throw new IllegalStateException("Could not save scanner report to temp file", e);
    }
  }

  private static long getSourceSize(File tempFile) {
    try {
      return Files.size(tempFile.toPath());
    } catch (IOException e) {
      throw new IllegalStateException("Could not check the size of the report temp file", e);
    }
  }

  public int splitFile(File bigFile, long sourceSize, long reportPartMaxSizeBytes, DbSession dbSession, CeTaskSubmit.Builder submit) {
    int position = 0;
    LOGGER.debug("Splitting report file {} of size {}", bigFile.toPath(), sourceSize);
    try (RandomAccessFile sourceFile = new RandomAccessFile(bigFile, "r");
         FileChannel sourceChannel = sourceFile.getChannel()) {

      final long numSplits = sourceSize / reportPartMaxSizeBytes;
      final long remainingBytes = sourceSize % reportPartMaxSizeBytes;
      LOGGER.debug("Report file {} will be split in {} parts", bigFile.toPath(), numSplits + (remainingBytes > 0 ? 1 : 0));

      for (; position < numSplits; position++) {
        //write multipart files.
        writePartToDb(dbSession, submit, reportPartMaxSizeBytes, position, sourceChannel, reportPartMaxSizeBytes);
      }
      if (remainingBytes > 0) {

View on GitHub (pinned to 184c821202)

Solutions

  1. Check that no cleaner (tmpwatch, tmpfiles.d) removes files during submissions
  2. Ensure each submission uses a unique temp file / dedicated temp directory
  3. Inspect storage health (dmesg, mount errors) if on NFS or ephemeral disks
  4. Retry the report submission; persistent occurrences need server log analysis of the cause
Defensive patterns

Strategy: retry

Validate before calling

Path tmp = Paths.get(System.getProperty("java.io.tmpdir"));
assert Files.exists(tmp) && Files.isWritable(tmp) && Files.getFileStore(tmp).getUsableSpace() > minFree;

Try / catch

try { submit(report); } catch (ServerException e) { retryOnceAfterFsCheck(); }

Prevention

When it happens

Trigger: Files.size(tempFile.toPath()) throws because the temp file was removed by a concurrent cleanup, or the filesystem returned an IO error after the copy step.

Common situations: Aggressive tmpwatch/systemd-tmpfiles cleaning during large uploads; NFS/ephemeral storage hiccups; the same temp path reused concurrently by multiple threads in a misconfigured deployment.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors


AI-assisted analysis of SonarSource/sonarqube@184c821202 (2026-09-09). Data as JSON: /api/errors/1eff70be1c9f0260. Report an issue: GitHub.