phacility/phabricator · error · Exception

Failed to parse `%s` output: %s

Error message

Failed to parse `%s` output: %s

What it means

Each output line of 'git cat-file --batch-check' is expected to contain at least two space-separated fields: the object identifier and its type (plus optional size). A line with fewer than two fields cannot be interpreted, so the query throws and includes the raw offending line in the message.

Source

Thrown at src/applications/diffusion/query/lowlevel/DiffusionLowLevelResolveRefsQuery.php:154

    $future->write(implode("\n", $unresolved));
    list($stdout) = $future->resolvex();

    $lines = explode("\n", rtrim($stdout, "\n"));
    if (count($lines) !== count($unresolved)) {
      throw new Exception(
        pht(
          'Unexpected line count from `%s`!',
          'git cat-file'));
    }

    $hits = array();
    $tags = array();

    $lines = array_combine($unresolved, $lines);
    foreach ($lines as $ref => $line) {
      $parts = explode(' ', $line);
      if (count($parts) < 2) {
        throw new Exception(
          pht(
            'Failed to parse `%s` output: %s',
            'git cat-file',
            $line));
      }
      list($identifier, $type) = $parts;

      if ($type == 'missing') {
        // This is either an ambiguous reference which resolves to several
        // objects, or an invalid reference. For now, always treat it as
        // invalid. It would be nice to resolve all possibilities for
        // ambiguous references at some point, although the strategy for doing
        // so isn't clear to me.
        continue;
      }

      switch ($type) {
        case 'commit':

View on GitHub (pinned to 5720a38cfe)

Solutions

1. Sanitize refs (no newline characters) before resolving them
2. Run the same batch-check command manually with the same refs to inspect raw output
3. Check git version consistency across web/daemon hosts in the cluster
4. If output looks truncated, check disk space and repository health (git fsck)

try {
  $resolved = $query->execute();
} catch (Exception $ex) {
  // Batch stream unparseable: treat all submitted refs as invalid
  $resolved = array();
  phlog($ex);
}

When it happens

Trigger: An empty or single-token line in the batch output: usually a trailing blank line after a newline-containing ref desynchronized the stream, or git wrote an error or blank line where a batch record was expected.

Common situations: Same family as the line-count mismatch: refs with embedded newlines, git error text interleaved with batch output, or a repository/objects in a bad state.

Understand the failure class

• Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

• Unexpected number of output lines from "git diff-tree" when
• Unexpected line count from `%s`!
• Unexpected object type from `%s`: %s
• Failed to parse line '%s'.
• Unexpected command structure, expected '%s'.

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