phacility/phabricator · error · Exception
No object exists with PHID "%s".
Error message
No object exists with PHID "%s".
What it means
Thrown by PhabricatorEditEngine::newObjectFromIdentifier() when the identifier's PHID type is recognized (phid_get_type() is not UNKNOWN) so the engine routes to newObjectFromPHID(), but that query returns nothing. As with the ID path, policy filtering means the PHID may exist yet be invisible to the acting viewer.
Source
Thrown at src/applications/transactions/editengine/PhabricatorEditEngine.php:732
if (is_int($identifier) || ctype_digit($identifier)) {
$object = $this->newObjectFromID($identifier, $capabilities);
if (!$object) {
throw new Exception(
pht(
'No object exists with ID "%s".',
$identifier));
}
return $object;
}
$type_unknown = PhabricatorPHIDConstants::PHID_TYPE_UNKNOWN;
if (phid_get_type($identifier) != $type_unknown) {
$object = $this->newObjectFromPHID($identifier, $capabilities);
if (!$object) {
throw new Exception(
pht(
'No object exists with PHID "%s".',
$identifier));
}
return $object;
}
$target = id(new PhabricatorObjectQuery())
->setViewer($this->getViewer())
->withNames(array($identifier))
->executeOne();
if (!$target) {
throw new Exception(
pht(
'Monogram "%s" does not identify a valid object.',
$identifier));
}View on GitHub (pinned to 5720a38cfe)
Solutions
- Resolve the PHID first with conduit phid.query / conduit.phid.lookup or the object's *.search method (constraints.phids) using the same credentials
- If the PHID came from stale storage (queue, cache, exported sheet), re-resolve it from a monogram or ID before editing
- Check the object still exists and the acting user/token has edit capability on it
- Catch the exception and branch to a not-found/forbidden handler in the caller
Example fix
// before: editing a PHID captured earlier
$parameters = array('objectIdentifier' => $phid, 'transactions' => $transactions);
$result = $client->callMethod('maniphest.edit', $parameters);
// Exception: No object exists with PHID "PHID-TASK-...".
// after: verify the PHID resolves for this viewer first
$lookup = $client->callMethod('phid.query', array('names' => array($phid)));
if (empty($lookup[$phid])) {
// handle missing/invisible object
}
$result = $client->callMethod('maniphest.edit', $parameters); Defensive patterns
Strategy: validation
Validate before calling
// Resolve the PHID with the same credentials before editing:
$lookup = $client->callMethod('phid.query', array('names' => array($phid)));
if (empty($lookup[$phid])) {
// missing, deleted, or not visible; skip the edit
} Type guard
function isPlausiblePhid($phid) {
return is_string($phid) && preg_match('/^PHID-[A-Z]{4}-[A-Za-z0-9]{20,}\z/', $phid);
} Try / catch
try {
$result = $client->callMethod('maniphest.edit', $parameters);
} catch (ConduitClientException $ex) {
if (strpos($ex->getMessage(), 'No object exists with PHID') === 0) {
// drop stale PHID from your store and re-resolve from a monogram/id
} else {
throw $ex;
}
} Prevention
- Treat stored PHIDs as cache entries with re-resolution, not permanent truth
- After object deletions/imports, prune queued PHIDs before workers process them
- Validate PHID shape client-side to catch truncation/corruption early
When it happens
Trigger: Passing objectIdentifier="PHID-TASK-abcdef..." to an edit-engine Conduit method or /edit/ controller where the object was deleted, the PHID is malformed/fabricated, or the viewer lacks the requested capability on it.
Common situations: Chaining tools that carry PHIDs across systems or backups restored into a fresh install; scripts storing PHIDs long-term (objects get deleted); API tokens belonging to a user without permission on the object; passing a PHID of the right application but wrong concrete object type for the engine.
Related errors
- No object exists with ID "%s".
- Monogram "%s" does not identify a valid object.
- Failed to reload object identified by monogram "%s" when que
- Service type "%s" is unrecognized. Valid types are: %s.
- Transaction value when deleting Almanac properties must be a
AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21).
Data as JSON: /api/errors/ba1728e6aec3af61.
Report an issue: GitHub.