What causes "Unable to identify parent "%s"!" in phacility/phabricator?

Re-run discovery with 'bin/repository discover '; transient ordering gaps usually self-heal on the next pass

phacility/phabricator · error · Exception

Unable to identify parent "%s"!

Error message

Unable to identify parent "%s"!

What it means

Thrown during commit discovery while writing parent links: the engine read a commit's parent identifiers from the VCS, then queried the commit table for those identifiers under this repository ID, and at least one parent identifier had no row. Discovery normally walks history so parents are recorded before children; a missing parent row means history was walked out of order, the working copy is missing objects, or the commit rows belong to a different repository ID.

Source

Thrown at src/applications/repository/engine/PhabricatorRepositoryDiscoveryEngine.php:622

    try {
      // If this commit has parents, look up their IDs. The parent commits
      // should always exist already.

      $parent_ids = array();
      if ($parents) {
        $parent_rows = queryfx_all(
          $conn_w,
          'SELECT id, commitIdentifier FROM %T
            WHERE commitIdentifier IN (%Ls) AND repositoryID = %d',
          $commit->getTableName(),
          $parents,
          $repository->getID());

        $parent_map = ipull($parent_rows, 'id', 'commitIdentifier');

        foreach ($parents as $parent) {
          if (empty($parent_map[$parent])) {
            throw new Exception(
              pht('Unable to identify parent "%s"!', $parent));
          }
          $parent_ids[] = $parent_map[$parent];
        }
      } else {
        // Write an explicit 0 so we can distinguish between "really no
        // parents" and "data not available".
        if (!$repository->isSVN()) {
          $parent_ids = array(0);
        }
      }

      $commit->openTransaction();
        $commit->save();

        $data->setCommitID($commit->getID());
        $data->save();

View on GitHub (pinned to 5720a38cfe)

Solutions

Re-run discovery with 'bin/repository discover <repository>'; transient ordering gaps usually self-heal on the next pass
Run 'bin/repository pull' first so the working copy has all objects, then discover again
If history was rewritten intentionally, remove stale commit rows or re-import the repository so recorded history matches the VCS
Inspect the commit table for the missing identifier and confirm its repositoryID matches this repository

Defensive patterns

Strategy: retry

Try / catch

try {
  id(new PhabricatorRepositoryDiscoveryEngine())
    ->setRepository($repository)
    ->discoverCommits();
} catch (Exception $ex) {
  if (preg_match('/Unable to identify parent/', $ex->getMessage())) {
    // pull first so all objects exist, then rediscover next cycle
    id(new PhabricatorRepositoryPullEngine())
      ->setRepository($repository)
      ->pullRepository();
  }
}

Prevention

Run 'bin/repository pull' before discovery on mirrors that may be mid-sync
Avoid rewriting published history that Phabricator has already imported
Monitor discovery task failures per repository so gaps are caught early

When it happens

Trigger: History rewriting (rebase or filter-branch in git) changing parent chains between discovery runs; discovery racing against a mirror that is mid-sync and missing objects; a repository record reused after its commit rows were reset or partially lost; commits whose rows were assigned to another repositoryID.

Common situations: Force-pushed repositories where discovery sees a child before its new parents are recorded; restores from backup with partially lost commit rows; running discovery against an incomplete mirror.

Related errors

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