phacility/phabricator · error · Exception

Failed to load file ("%s") returned by "%s".

Error message

Failed to load file ("%s") returned by "%s".

What it means

diffusion.rawdiffquery returned a filePHID for the generated patch, but the immediately following PhabricatorFileQuery (omnipotent viewer) cannot load it (PhabricatorRepositoryCommitPublishWorker.php:411-422). This is an internal invariant break: the file was just written by the same pipeline, so realistic causes are aggressive file garbage collection or storage-engine trouble.

Source

Thrown at src/applications/repository/worker/PhabricatorRepositoryCommitPublishWorker.php:417

          new PhutilNumber($time_limit)));
    }

    if ($diff_info['tooHuge']) {
      $pretty_limit = phutil_format_bytes($byte_limit);
      throw new Exception(
        pht(
          'Patch size exceeds configured byte size limit ("%s") of %s.',
          $byte_key,
          $pretty_limit));
    }

    $file_phid = $diff_info['filePHID'];
    $file = id(new PhabricatorFileQuery())
      ->setViewer($viewer)
      ->withPHIDs(array($file_phid))
      ->executeOne();
    if (!$file) {
      throw new Exception(
        pht(
          'Failed to load file ("%s") returned by "%s".',
          $file_phid,
          'diffusion.rawdiffquery'));
    }

    return $file->loadFileData();
  }

  private function closeRevisions(
    PhabricatorUser $actor,
    PhabricatorRepositoryCommit $commit) {

    $differential = 'PhabricatorDifferentialApplication';
    if (!PhabricatorApplication::isClassInstalled($differential)) {
      return;
    }

View on GitHub (pinned to 5720a38cfe)

Solutions

1. Look up the reported file PHID in the Files application or the file table to see if/when it vanished
2. Check file storage config and GC TTL; raise storage.ttl if it was set very low
3. Fix storage engine issues, then re-run publishing for the commit so a fresh patch file is generated

// Verify the file backend is healthy before publish runs (operational check):
//   bin/storage status
// and ensure storage TTL is not shorter than your publish queue lag.

try {
  $data = $this->loadRawPatchText($repository, $commit);
} catch (Exception $ex) {
  // File vanished between generation and load (GC/TTL or storage flake):
  // transient by nature - let the task retry, which regenerates the file.
  phlog($ex);
  throw $ex;
}

When it happens

Trigger: File GC (a very short storage TTL) deleting the patch file between generation and load; a flaky custom storage backend (e.g., S3) losing the just-written object; a DB transaction rollback between the two steps.

Common situations: Aggressive storage.ttl configuration; misconfigured or throttled blob storage; partial restores of the file table.

Related errors

• File data integrity check failed. Use "--salvage" to bypass
• Failed to reload commit "%s".
• Service "%s" is unrecognized, restricted, or you do not have
• When creating a new Almanac interface via the Conduit API, y
• Device "%s" is unrecognized, restricted, or you do not have

AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/21fdfac0b38709a5. Report an issue: GitHub.