What causes "Some patches could not be applied: %s" in phacility/phabricator?

Run `./bin/storage status` to see per-host applied state and identify the first patch missing everywhere.

phacility/phabricator · error · Exception

Some patches could not be applied: %s

Error message

Some patches could not be applied: %s

What it means

The upgrade patch loop finished an iteration having applied nothing while patches remain, so every pending patch is blocked: its `after` dependency is not applied on any eligible host. In practice an earlier patch failed somewhere (query error, timeout, privilege problem) and everything depending on it stayed stuck; the tool gives up and lists the leftover patch keys.

Source

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

          // If we're explicitly reapplying this patch, we don't need to
          // mark it as applied.
          if (!isset($state_map[$ref_key][$key])) {
            if (!$is_dryrun) {
              $api->markPatchApplied($key, ($t_end - $t_begin));
            }
            $applied_map[$ref_key][$key] = true;
          }
        }

        // We applied this everywhere, so we're done with the patch.
        unset($patches[$key]);
        $applied_something = true;
      }

      if (!$applied_something) {
        if ($patches) {
          throw new Exception(
            pht(
              'Some patches could not be applied: %s',
              implode(', ', array_keys($patches))));
        } else if (!$is_dryrun && !$apply_only) {
          echo pht(
            'Storage is up to date. Use "%s" for details.',
            'storage status')."\n";
        }
        break;
      }
    }
  }

  final protected function getBareHostAndPort($host) {
    // Split out port information, since the command-line client requires a
    // separate flag for the port.
    $uri = new PhutilURI('mysql://'.$host);
    if ($uri->getPort()) {

View on GitHub (pinned to 5720a38cfe)

Solutions

Run `./bin/storage status` to see per-host applied state and identify the first patch missing everywhere.
Inspect that patch (resources/sql/patches/<key>.sql) and fix the underlying MySQL issue: privileges, lock timeouts, max_allowed_packet, index size limits, sql_mode.
Re-run `./bin/storage upgrade`; patches whose dependencies now succeed will proceed.
If a size limit is the cause, adjust the MySQL settings for that host rather than editing the patch.

Defensive patterns

Strategy: try-catch

Try / catch

try {
  // bin/storage upgrade
} catch (Exception $ex) {
  // message lists stuck patch keys; run ./bin/storage status, fix the first
  // failed patch's underlying MySQL issue, then re-run the upgrade
  fwrite(STDERR, $ex->getMessage()."\n");
  exit(1);
}

Prevention

Run ./bin/storage status before and after upgrades to catch per-host drift early.
Schedule upgrades on large tables inside a maintenance window to avoid lock timeouts.
Resolve the first stuck patch before re-running; blind retries loop on the same failure.

When it happens

Trigger: An earlier patch failed on one or more hosts (lock timeout, SQL error, oversized index, missing privileges), so no host satisfies the dependencies of the remaining patches; the loop sets $applied_something false with $patches non-empty and throws the list of stuck keys.

Common situations: MySQL rejecting a patch (index prefix limits, sql_mode); timeouts altering large tables mid-upgrade; partial failure across a cluster where one host failed a patch; resuming an upgrade after an aborted run.

Related errors

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