phacility/phabricator · error · Exception

Commit "%s" has not been discovered yet! Run discovery befor

Error message

Commit "%s" has not been discovered yet! Run discovery before updating refs.

What it means

Thrown by PhabricatorRepositoryRefEngine while updating ref cursors: the engine has identifiers of commits reachable from new ref positions, but one is absent from the already-discovered commit rows loaded for this repository. Ref updates require discovery to have run first; a missing row means refs moved ahead of discovery or the two raced, which would otherwise create cursors pointing at nonexistent commits.

Source

Thrown at src/applications/repository/engine/PhabricatorRepositoryRefEngine.php:574

      // these records out in detail.

      $commit_refs[] = id(new PhabricatorRepositoryCommitRef())
        ->setIdentifier($identifier);
    }

    $task_priority = $this->getImportTaskPriority(
      $repository,
      $commit_refs);

    $permanent_flag = PhabricatorRepositoryCommit::IMPORTED_PERMANENT;
    $published_flag = PhabricatorRepositoryCommit::IMPORTED_PUBLISH;

    $all_commits = ipull($all_commits, null, 'commitIdentifier');
    foreach ($identifiers as $identifier) {
      $row = idx($all_commits, $identifier);

      if (!$row) {
        throw new Exception(
          pht(
            'Commit "%s" has not been discovered yet! Run discovery before '.
            'updating refs.',
            $identifier));
      }

      $import_status = $row['importStatus'];
      if (!($import_status & $permanent_flag)) {
        // Set the "permanent" flag.
        $import_status = ($import_status | $permanent_flag);

        // See T13580. Clear the "published" flag, so publishing executes
        // again. We may have previously performed a no-op "publish" on the
        // commit to make sure it has all bits in the "IMPORTED_ALL" bitmask.
        $import_status = ($import_status & ~$published_flag);

        queryfx(
          $conn,

View on GitHub (pinned to 5720a38cfe)

Solutions

Run discovery manually: 'bin/repository discover R123', then let the ref task retry or run 'bin/repository refs R123'
Check the task queue for a failed discovery task, fix its underlying error, and retry it with 'bin/worker retry <task-id>'
If using Import Only, make sure tracked refs do not point at commits outside the subpath, or widen the subpath
If it recurs steadily, look for an earlier discovery engine error in the logs for the same repository

Example fix

# before
bin/repository refs R123   # throws: commit not discovered yet

# after
bin/repository discover R123
bin/repository refs R123

Defensive patterns

Strategy: retry

Try / catch

try {
  id(new PhabricatorRepositoryRefEngine())
    ->setRepository($repository)
    ->updateRefs();
} catch (Exception $ex) {
  if (preg_match('/has not been discovered yet/', $ex->getMessage())) {
    id(new PhabricatorRepositoryDiscoveryEngine())
      ->setRepository($repository)
      ->discoverCommits(); // then retry the ref update
  }
}

Prevention

Let discovery complete before manual ref updates: discover first, then refs
Watch for failed discovery tasks; ref errors are usually downstream symptoms
Scope Import Only subpaths to cover everything reachable from tracked refs

When it happens

Trigger: A ref update task executing before the discovery task for the same new commits (task scheduling race); discovery partially failed or was interrupted after refs were fetched; commits reachable from refs but excluded by an Import Only subpath; discovery stuck or errored earlier for this repository.

Common situations: Pushes arriving while discovery is behind on a large repo; daemons stopped mid-import; SVN repositories with subpath import where a ref points outside the imported subpath.

Related errors

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