phacility/phabricator · warning · PhutilArgumentUsageException

Unable to find any object with the specified name ("%s").

Error message

Unable to find any object with the specified name ("%s").

What it means

The object name passed to bin/policy unlock is resolved with PhabricatorObjectQuery::withNames; a null result throws this usage exception, so there is nothing to unlock. Names resolve under the workflow's viewer, so invisible objects are indistinguishable from nonexistent ones.

Source

Thrown at src/applications/policy/management/PhabricatorPolicyManagementUnlockWorkflow.php:69

    $viewer = $this->getViewer();

    $object_names = $args->getArg('objects');
    if (!$object_names) {
      throw new PhutilArgumentUsageException(
        pht('Specify the name of an object to unlock.'));
    } else if (count($object_names) > 1) {
      throw new PhutilArgumentUsageException(
        pht('Specify the name of exactly one object to unlock.'));
    }

    $object_name = head($object_names);

    $object = id(new PhabricatorObjectQuery())
      ->setViewer($viewer)
      ->withNames(array($object_name))
      ->executeOne();
    if (!$object) {
      throw new PhutilArgumentUsageException(
        pht(
          'Unable to find any object with the specified name ("%s").',
          $object_name));
    }

    $view_user = $this->loadUser($args->getArg('view'));
    $edit_user = $this->loadUser($args->getArg('edit'));
    $owner_user = $this->loadUser($args->getArg('owner'));

    if (!$view_user && !$edit_user && !$owner_user) {
      throw new PhutilArgumentUsageException(
        pht(
          'Choose which capabilities to unlock with "--view", "--edit", '.
          'or "--owner".'));
    }

    $handle = id(new PhabricatorHandleQuery())
      ->setViewer($viewer)

View on GitHub (pinned to 5720a38cfe)

Solutions

  1. Confirm the name resolves with ./bin/phid lookup, then retry with the exact monogram.
  2. If the object truly is gone, nothing needs unlocking; drop it from the runbook.

Example fix

# before
./bin/policy unlock D9999 --edit alice
# after
./bin/phid lookup D1234   # confirm, then
./bin/policy unlock D1234 --edit alice
Defensive patterns

Strategy: validation

Validate before calling

name='D1234'
out=$(./bin/phid lookup "$name")
[ -n "$out" ] || { echo "unknown object: $name" >&2; exit 1; }
./bin/policy unlock "$name" --edit alice

Prevention

When it happens

Trigger: ./bin/policy unlock D99999 with a misspelled monogram or PHID, or with a name that came from another install.

Common situations: Rescuing a task or paste whose monogram was transcribed incorrectly, and stale runbooks referencing deleted objects.

Related errors


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