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
- Check that no cleaner (tmpwatch, tmpfiles.d) removes files during submissions
- Ensure each submission uses a unique temp file / dedicated temp directory
- Inspect storage health (dmesg, mount errors) if on NFS or ephemeral disks
- 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
- Disable tmpwatch/tmpfiles during CI windows
- Use local (non-NFS) temp storage
- Keep uploads and stat of temp files within one node
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
- Can not write to file
- Could not save scanner report to temp file
- Failed to split report for task ${uuid}
- Could not save report ${uuid} part ${partNumber} file to dat
- %s for request [%s]: [%s]
AI-assisted analysis of SonarSource/sonarqube@184c821202 (2026-09-09).
Data as JSON: /api/errors/1eff70be1c9f0260.
Report an issue: GitHub.