phacility/phabricator · error · PhutilArgumentUsageException

Specified blueprint "%s" is not capable of satisfying the co

Error message

Specified blueprint "%s" is not capable of satisfying the configured lease.

What it means

A PhutilArgumentUsageException from `bin/drydock lease --blueprint`: the explicit blueprint filter includes a blueprint whose class is not among the classes that could plausibly allocate the requested lease (the allowed set computed from getAllForAllocatingLease plus enabled blueprints). Typically the resource type and the filtered blueprint disagree — e.g. requesting --type host while filtering to a working-copy blueprint.

Source

Thrown at src/applications/drydock/management/DrydockManagementLeaseWorkflow.php:350

      ->withDisabled(false)
      ->execute();

    if (!$blueprints) {
      throw new PhutilArgumentUsageException(
        pht(
          'No enabled blueprints exist with a blueprint class that can '.
          'plausibly allocate resources to satisfy the requested lease.'));
    }

    $phids = mpull($blueprints, 'getPHID');

    if ($filter_blueprints) {
      $allowed_map = array_fuse($phids);
      $filter_map = mpull($filter_blueprints, null, 'getPHID');

      foreach ($filter_map as $filter_phid => $blueprint) {
        if (!isset($allowed_map[$filter_phid])) {
          throw new PhutilArgumentUsageException(
            pht(
              'Specified blueprint "%s" is not capable of satisfying the '.
              'configured lease.',
              $blueprint->getBlueprintName()));
        }
      }

      $phids = mpull($filter_blueprints, 'getPHID');
    }

    return $phids;
  }

}

View on GitHub (pinned to 5720a38cfe)

Solutions

Match the filter to the type: use a blueprint whose implementation class provides the resource type you pass to --type.
Or drop --blueprint entirely and let Drydock choose among all capable blueprints.
Verify the pairing by opening the blueprint and checking its type/implementation matches --type.

Example fix

# before
bin/drydock lease --type working-copy --blueprint 3   # 3 is a 'host' blueprint

# after
bin/drydock lease --type working-copy --blueprint 7   # 7 is a 'working-copy' blueprint
# or simply
bin/drydock lease --type working-copy

Defensive patterns

Strategy: validation

Validate before calling

// compute the allowed set, then intersect with the requested filter
$impls = DrydockBlueprintImplementation::getAllForAllocatingLease($probe);
$allowed = id(new DrydockBlueprintQuery())
  ->setViewer($viewer)
  ->withBlueprintClasses(array_keys($impls))
  ->withDisabled(false)
  ->execute();
$allowed_phids = array_fuse(mpull($allowed, 'getPHID'));
foreach ($filter_phids as $phid) {
  if (!isset($allowed_phids[$phid])) {
    throw new InvalidArgumentException(
      'Filtered blueprint cannot serve this resource type.');
  }
}

Prevention

Pair --blueprint filters with the matching --type; update both together when automation changes.
Prefer omitting --blueprint unless you specifically need to pin allocation — unfiltered leases let Drydock choose a capable blueprint.

When it happens

Trigger: `bin/drydock lease --type working-copy --blueprint <host-blueprint-id>`: the host blueprint's PHID is absent from $allowed_map, so the workflow rejects the combination before leasing.

Common situations: Copy-pasting a blueprint ID from documentation for a different resource type; renaming resource types in scripts while the blueprint filter still targets the old pairing; multiple blueprints of different classes with similar names.

Related errors

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