phacility/phabricator · error · Exception

Database initialization on host "%s" applied no patches!

Error message

Database initialization on host "%s" applied no patches!

What it means

After the initialization loop, a host still reports getAppliedPatches() === null — its patch status table is missing or unreadable — even though this was not a dry run. The tool expected initialization to leave patch state behind and throws rather than continue from unknown state.

Source

Thrown at src/infrastructure/storage/management/workflow/PhabricatorStorageManagementWorkflow.php:1011

    }

    if ($init_only) {
      echo pht('Storage initialized.')."\n";
      return 0;
    }

    $applied_map = array();
    $state_map = array();
    foreach ($api_map as $ref_key => $api) {
      $applied = $api->getAppliedPatches();

      // If we still have nothing applied, this is a dry run and we didn't
      // actually initialize storage. Here, just do nothing.
      if ($applied === null) {
        if ($is_dryrun) {
          continue;
        } else {
          throw new Exception(
            pht(
              'Database initialization on host "%s" applied no patches!',
              $ref_key));
        }
      }

      $applied = array_fuse($applied);
      $state_map[$ref_key] = $applied;

      if ($apply_only) {
        if (isset($applied[$apply_only])) {
          if (!$this->force && !$is_dryrun) {
            echo phutil_console_wrap(
              pht(
                'Patch "%s" has already been applied on host "%s". Are you '.
                'sure you want to apply it again? This may put your storage '.
                'in a state that the upgrade scripts can not automatically '.
                'manage.',

View on GitHub (pinned to 5720a38cfe)

Solutions

  1. Check that the connecting DB account may create and write tables in the target databases (grant all on the Phabricator DBs).
  2. Re-run `./bin/storage upgrade`; initialization is idempotent and will retry creating patch state.
  3. Inspect the host with `./bin/storage status` and, if needed, look at its databases directly to see what was created.
  4. Check the MySQL error log for the earlier failure that left initialization half-done.
Defensive patterns

Strategy: try-catch

Try / catch

try {
  // bin/storage upgrade across hosts
} catch (Exception $ex) {
  // patch state missing on a host; inspect with ./bin/storage status before retrying
  fwrite(STDERR, $ex->getMessage()."\n");
  exit(1);
}

Prevention

When it happens

Trigger: A host that went through init but has no readable patch status: an interrupted first run (Ctrl-C, crash), a DB account lacking privileges to create or write the patch status table, or someone dropping the metadata tables mid-run.

Common situations: Interrupted first bin/storage upgrade; MySQL user missing CREATE/INSERT on the target databases; concurrent re-initialization by another admin; earlier silent failures creating tables (max_allowed_packet, disk full).

Related errors


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