phacility/phabricator · warning · PhutilArgumentUsageException

Storage on host "%s" has not been initialized yet. You must

Error message

Storage on host "%s" has not been initialized yet. You must initialize storage before selectively applying patches.

What it means

`bin/storage upgrade --apply <patch>` ran against a host whose storage has never been initialized (its databases do not exist yet, so there is no patch state). Selectively applying one patch presupposes initialized storage, so the tool refuses; in a dry run the same situation only prints what would be created.

Source

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

      $applied = $api->getAppliedPatches();

      $needs_init = ($applied === null);
      if (!$needs_init) {
        continue;
      }

      if ($is_dryrun) {
        echo tsprintf(
          "%s\n",
          pht(
            'DRYRUN: Storage on host "%s" does not exist yet, so it '.
            'would be created.',
            $ref_key));
        continue;
      }

      if ($apply_only) {
        throw new PhutilArgumentUsageException(
          pht(
            'Storage on host "%s" has not been initialized yet. You must '.
            'initialize storage before selectively applying patches.',
            $ref_key));
      }

      // If we're initializing storage for the first time on any host, track
      // it so that we can give the user a nicer experience during the
      // subsequent adjustment phase.
      $this->didInitialize = true;

      $legacy = $api->getLegacyPatches($patches);
      if ($legacy || $no_quickstart || $init_only) {
        // If we have legacy patches, we can't quickstart.
        $api->createDatabase('meta_data');
        $api->createTable(
          'meta_data',
          'patch_status',

View on GitHub (pinned to 5720a38cfe)

Solutions

Initialize first with a plain `./bin/storage upgrade` (no --apply); use --apply only for later single patches.
Confirm host state with `./bin/storage status` — uninitialized hosts are reported.
In bring-up scripts, gate any --apply step on the host showing as initialized.

Example fix

# before (fresh install)
./bin/storage upgrade --apply db.file.01

# after
./bin/storage upgrade                    # initialize all storage first
./bin/storage upgrade --apply db.file.01  # later, for a single patch

Defensive patterns

Strategy: validation

Validate before calling

if ! ./bin/storage status 2>/dev/null | grep -q 'Applied'; then
  echo 'storage not initialized yet; run ./bin/storage upgrade first' >&2
  exit 2
fi
./bin/storage upgrade --apply "$KEY"

Prevention

Sequence host bring-up: initialize with plain upgrade, then use --apply.
Run ./bin/storage status before any selective patch command on a new host.

When it happens

Trigger: Running `./bin/storage upgrade --apply <key>` on a fresh install or a newly added cluster host where the Phabricator databases do not exist yet ($apply_only set on an uninitialized host).

Common situations: Bringing a new cluster host online and jumping straight to --apply from a runbook; new developer machines; re-running an init procedure that was interrupted before the databases were created.

Related errors

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