What causes "Failed to reload commit "%s"." in phacility/phabricator?

Verify the commit still exists (query repository_commit by PHID) and that its repository is intact

phacility/phabricator · error · PhabricatorWorkerPermanentFailureException

Failed to reload commit "%s".

Error message

Failed to reload commit "%s".

What it means

PhabricatorRepositoryCommitPublishWorker re-loads the commit with data, identities, and audit requests attached before publishing notifications (PhabricatorRepositoryCommitPublishWorker.php:36-51). The viewer is omnipotent, so a failed reload is not a policy problem - the commit row itself vanished between task queuing and execution, and the task permanently fails.

Source

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

  private function publishCommit(
    PhabricatorRepository $repository,
    PhabricatorRepositoryCommit $commit) {
    $viewer = PhabricatorUser::getOmnipotentUser();

    $commit_phid = $commit->getPHID();

    // Reload the commit to get the commit data, identities, and any
    // outstanding audit requests.
    $commit = id(new DiffusionCommitQuery())
      ->setViewer($viewer)
      ->withPHIDs(array($commit_phid))
      ->needCommitData(true)
      ->needIdentities(true)
      ->needAuditRequests(true)
      ->executeOne();
    if (!$commit) {
      throw new PhabricatorWorkerPermanentFailureException(
        pht(
          'Failed to reload commit "%s".',
          $commit_phid));
    }

    $publisher = $repository->newPublisher();
    $should_publish = $publisher->shouldPublishCommit($commit);

    if (!$should_publish) {
      $hold_reasons = $publisher->getCommitHoldReasons($commit);
    } else {
      $hold_reasons = array();
    }

    $data = $commit->getCommitData();
    if ($data->getCommitDetail('holdReasons') !== $hold_reasons) {
      $data->setCommitDetail('holdReasons', $hold_reasons);
      $data->save();

View on GitHub (pinned to 5720a38cfe)

Solutions

Verify the commit still exists (query repository_commit by PHID) and that its repository is intact
If the deletion was intentional, let the task expire - permanent failure is the designed outcome
If the rows were restored or recreated, re-run parsing/publishing for the commit so a fresh publish task is queued (bin/repository reparse)

Defensive patterns

Strategy: try-catch

Validate before calling

// Before publishing, confirm the commit still loads with data attached.
$reloaded = id(new DiffusionCommitQuery())
  ->setViewer(PhabricatorUser::getOmnipotentUser())
  ->withPHIDs(array($commit->getPHID()))
  ->needCommitData(true)
  ->executeOne();
if (!$reloaded) {
  // commit row vanished; drop the publish task
}

Try / catch

try {
  $this->loadCommit($viewer, $repository);
} catch (PhabricatorWorkerPermanentFailureException $ex) {
  // Commit deleted mid-queue (usually repository removal): permanent
  // failure is correct; archive the task and log for audit.
  phlog($ex);
}

Prevention

Delete or drain publish queues before removing repositories
After restores, verify pending tasks still reference existing rows
Treat permanent publish failures as audit events, not transient errors

When it happens

Trigger: The repository or commit rows were deleted while publish tasks were pending; a partial database restore removed commit rows but left the worker queue intact.

Common situations: Deleting repositories with pending publish tasks; database maintenance/restore operations that skip the worker queue.

Related errors

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