SonarSource/sonarqube · error · TooManyFileMovesDetectedException

Analysis Failed. --------------------- REASON: Potential Out

Error message

Analysis Failed.
---------------------
REASON: Potential Out-Of-Memory (OOM) Risk Detected.
The Compute Engine detected an excessively large volume of potential file moves: %d added files and %d removed files.
- Estimated heap needed for File Move Detection: %.1f GB.
- Detected heap size allocated to Compute Engine: %.1f GB.
The scan failed proactively to avoid an out-of-memory failure on the server.

NEXT STEPS (Choose One):

  1. Unintended Move (Mistake):
Please revert the project structure to the previous commit and re-run the analysis.

  2. Intended Move (Legitimate Restructure):
The volume of moved/renamed files is too large to be processed. Please restore the old structure, and perform this move in multiple batches, each followed by analysis.
---------------------

What it means

HeapSizeCheckerImpl.checkHeapLimits() estimates the heap needed by the File Move Detection step as addedFiles × removedFiles × 4 bytes (an int matrix) and compares it to the Compute Engine's max heap (maxMemory). If the estimate exceeds or equals the available heap, it throws TooManyFileMovesDetectedException with this detailed message, aborting the analysis proactively instead of letting the CE crash with an OutOfMemoryError.

Source

Thrown at server/sonar-ce-task-projectanalysis/src/main/java/org/sonar/ce/task/projectanalysis/filemove/HeapSizeCheckerImpl.java:44

  private final long maxMemory;

  public HeapSizeCheckerImpl() {
    this(Runtime.getRuntime().maxMemory());
  }

  @VisibleForTesting
  HeapSizeCheckerImpl(long maxMemory) {
    this.maxMemory = maxMemory;
  }

  @Override
  public void checkHeapLimits(int totalAddedFiles, int totalRemovedFiles) {
    long matrixSize = (long) totalAddedFiles * totalRemovedFiles;
    double heapSizeInGb = toGb(maxMemory);
    double estimatedHeapNeededInGb = toGb(matrixSize * Integer.BYTES);

    if (heapSizeInGb <= estimatedHeapNeededInGb) {
      throw new TooManyFileMovesDetectedException(totalAddedFiles, totalRemovedFiles, heapSizeInGb, estimatedHeapNeededInGb);
    }
  }

  private static double toGb(long bytes) {
    return (double) bytes / 1024.0F / 1024.0F / 1024.0F;
  }

}

View on GitHub (pinned to 184c821202)

Solutions

  1. Revert the restructuring and redo it in multiple smaller batches, running an analysis after each batch (as the message's NEXT STEPS suggests)
  2. Increase the Compute Engine heap: raise SONAR_CE_JAVAOPTS/-Xmx (e.g. -Xmx8g) so it exceeds added×removed×4 bytes
  3. If the mass add/remove is unintended, restore the previous project structure and re-run the analysis

Example fix

// before: one giant rename analyzed at once
$ git mv oldpkg newpkg  # 20,000 files
$ sonar-scanner  // fails
// after: batch the move
$ git mv oldpkg/sub1 newpkg/sub1 && sonar-scanner
$ git mv oldpkg/sub2 newpkg/sub2 && sonar-scanner
// or raise heap
SONAR_CE_JAVAOPTS="-Xmx8g"
Defensive patterns

Strategy: try-catch

Validate before calling

// estimate before launching analysis
long added = countAddedFiles(diff);
long removed = countRemovedFiles(diff);
double neededGb = (double) (added * (long) removed * Integer.BYTES) / 1024 / 1024 / 1024;
if (neededGb >= ceHeapGb) {
  System.out.println("Split the move into batches or increase CE -Xmx above " + neededGb + " GB");
}

Try / catch

try {
  analysis = computeEngine.analyze(project);
} catch (TooManyFileMovesDetectedException e) {
  // message includes added/removed counts and needed vs allocated heap
  logger.warn("File move detection aborted: {} added / {} removed files", e.getTotalAddedFiles(), e.getTotalRemovedFiles());
  // batch the restructure or raise -Xmx, then retry
}

Prevention

When it happens

Trigger: Running a project analysis where the report adds N files and removes M files such that N*M*sizeof(int) >= CE heap — typical of a large-scale directory move/rename committed in one analysis, or a branch scan against a drastically restructured tree.

Common situations: Renaming a top-level package/directory touching thousands of files at once, migrating a monorepo layout in a single commit, or running on a CE with a small -Xmx while the project has tens of thousands of moved files.

Understand the failure class

Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.

Related errors

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