phacility/phabricator · warning · PhutilArgumentUsageException

Public key with ID %s is already trusted.

Error message

Public key with ID %s is already trusted.

What it means

Usage exception from `bin/almanac trust-key`: the addressed key already has isTrusted set, so the command has nothing to do and aborts rather than pretending to change state. This is effectively an idempotency guard; it usually appears when re-running a provisioning script, or when the trust step succeeded earlier and the failure the operator is chasing (e.g. in register) lies elsewhere.

Source

Thrown at src/applications/almanac/management/AlmanacManagementTrustKeyWorkflow.php:44

        pht('Specify a public key to trust with --id.'));
    }

    $key = id(new PhabricatorAuthSSHKeyQuery())
      ->setViewer($this->getViewer())
      ->withIDs(array($id))
      ->executeOne();
    if (!$key) {
      throw new PhutilArgumentUsageException(
        pht('No public key exists with ID "%s".', $id));
    }

    if (!$key->getIsActive()) {
      throw new PhutilArgumentUsageException(
        pht('Public key "%s" is not an active key.', $id));
    }

    if ($key->getIsTrusted()) {
      throw new PhutilArgumentUsageException(
        pht('Public key with ID %s is already trusted.', $id));
    }

    if (!($key->getObject() instanceof AlmanacDevice)) {
      throw new PhutilArgumentUsageException(
        pht('You can only trust keys associated with Almanac devices.'));
    }

    $handle = id(new PhabricatorHandleQuery())
      ->setViewer($this->getViewer())
      ->withPHIDs(array($key->getObject()->getPHID()))
      ->executeOne();

    $console->writeOut(
      "**<bg:red> %s </bg>**\n\n%s\n\n%s\n\n%s",
      pht('IMPORTANT!'),
      phutil_console_wrap(
        pht(

View on GitHub (pinned to 5720a38cfe)

Solutions

  1. Treat it as success if this is the key you wanted trusted; proceed to bin/almanac register.
  2. If register still says 'not yet trusted', verify you trusted the key whose ID register is actually using for THAT device (compare IDs on the device's key list).
  3. Make provisioning scripts check state first (or tolerate this specific message) instead of unconditionally calling trust-key.

Example fix

# before (script always trusts)
bin/almanac trust-key --id 42 || exit 1

# after (tolerate the already-trusted case)
bin/almanac trust-key --id 42 || \
  grep -q 'already trusted' /dev/stdin <<<"$output" || exit 1
# simpler: run trust-key, ignore failure whose message contains 'already trusted'
Defensive patterns

Strategy: fallback

Validate before calling

// Skip trust when already trusted
if (!$key->getIsTrusted()) {
  // proceed: bin/almanac trust-key --id <id>
} else {
  // already trusted; nothing to do
}

Try / catch

# idempotent shell trust step
out=$(bin/almanac trust-key --id "$KEY_ID" 2>&1) || {
  echo "$out" | grep -q 'already trusted' || { echo "$out" >&2; exit 1; }
  echo "key $KEY_ID already trusted; continuing"
}

Prevention

When it happens

Trigger: Re-running trust-key after it already succeeded; a runbook that unconditionally trusts before register, executed twice; register still complaining about trust because the trusted key belongs to a DIFFERENT device than the one being registered.

Common situations: Non-idempotent provisioning scripts; debugging register's 'not yet trusted' error and firing trust-key at the wrong key ID; key rotation where the old key remains trusted.

Related errors


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