What causes "Expected '%s', got %s." in phacility/phabricator?

Run the same svn ls --xml command manually as the daemon user - the real error is usually on the first lines

phacility/phabricator · error · Exception

Expected '%s', got %s.

Error message

Expected '%s', got %s.

What it means

The first line of svn ls --xml output must match /^<?xml version="1.0".*?>/; if svn prints any warning, banner, or error text before the declaration (or omits it), the parse throws immediately (PhabricatorRepositorySvnCommitChangeParserWorker.php:716-727). In practice this error usually masks the real problem: svn failed (auth, cert, connection) and emitted a message instead of XML.

Source

Thrown at src/applications/repository/worker/commitchangeparser/PhabricatorRepositorySvnCommitChangeParserWorker.php:719

          if ($line == '</list>') {
            $done = true;
            break 2;
          } else if ($line == '<entry') {
            $mode = 'entry';
            $entry = array();
          } else {
            throw new Exception(
              pht(
                'Expected %s or %s, got %s.',
                '</list>',
                '<entry',
                $line));
          }
          break;
        case 'xml':
          $expect = '/<?xml version="1.0".*?>/';
          if (!preg_match($expect, $line)) {
            throw new Exception(
              pht(
                "Expected '%s', got %s.",
                $expect,
                $line));
          }
          $mode = 'list';
          break;
        case 'list':
          $expect = '<lists>';
          if ($line !== $expect) {
            throw new Exception(
              pht(
                "Expected '%s', got %s.",
                $expect,
                $line));
          }
          $mode = 'list1';
          break;

View on GitHub (pinned to 5720a38cfe)

Solutions

Run the same svn ls --xml command manually as the daemon user - the real error is usually on the first lines
Fix the underlying svn problem: credentials, cert trust, network reachability
Remove any wrappers/banners so stdout contains only the XML document

Defensive patterns

Strategy: validation

Validate before calling

// Pre-flight the exact command the parser runs and check the first line:
//   out=$(svn ls --xml <repo-url> 2>/dev/null); head -1 <<< "$out"
// It must match ^<?xml version="1.0".*?> - otherwise fix svn auth/cert/network first.

Type guard

function looksLikeSvnListXml($first_line) {
  return (bool)preg_match('/<\?xml version="1\.0".*\?>/', $first_line);
}

Try / catch

try {
  $map = $this->parseSVNListXML($file_path);
} catch (Exception $ex) {
  // First line was not the XML declaration: svn almost certainly failed
  // (auth/cert/network) and printed a message. Read the captured output,
  // fix the underlying svn issue, then reparse.
  phlog(file_get_contents($file_path));
  throw new PhabricatorWorkerPermanentFailureException($ex->getMessage());
}

Prevention

Monitor svn credentials and cert trust so svn never errors in place of XML
Run svn commands without wrappers or banners on daemon hosts
Log raw svn output on parse failure to expose the true svn error immediately

When it happens

Trigger: svn authentication failure or expired credentials printing an error instead of XML; SSL certificate warnings written to stdout; wrapper scripts or hooks adding banner output before the document.

Common situations: Expired SVN credentials; changed server certificates after admin renewal; locale or config noise from the svn client; misconfigured wrappers on the daemon host.

Related errors

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