phacility/phabricator · error · Exception
In call to "transaction.search", selected object (of type "%
Error message
In call to "transaction.search", selected object (of type "%s") does not implement "%s", so transactions can not be loaded for it.
What it means
After the template object resolves (from objectType or objectIdentifier), it must implement PhabricatorApplicationTransactionInterface for transaction.search to load its timeline; otherwise this Exception names both the concrete class and the interface. This is an API-shape limitation, not a permissions problem — some PHID-bearing objects (users, repositories, config records) simply have no application transaction timeline.
Source
Thrown at src/applications/transactions/conduit/TransactionSearchConduitAPIMethod.php:406
}
$object = $all_types[$object_type]->newObject();
} else {
$object = id(new PhabricatorObjectQuery())
->setViewer($viewer)
->withNames(array($object_identifier))
->executeOne();
if (!$object) {
throw new Exception(
pht(
'In call to "transaction.search", specified "objectIdentifier" '.
'("%s") does not exist.',
$object_identifier));
}
}
if (!($object instanceof PhabricatorApplicationTransactionInterface)) {
throw new Exception(
pht(
'In call to "transaction.search", selected object (of type "%s") '.
'does not implement "%s", so transactions can not be loaded for it.',
get_class($object),
'PhabricatorApplicationTransactionInterface'));
}
return $object;
}
}
View on GitHub (pinned to 5720a38cfe)
Solutions
- Use the application's own conduit API for non-transactional objects (e.g. user.search, repository.search).
- For custom applications, implement PhabricatorApplicationTransactionInterface and the associated transaction query to opt in.
- Target transactional objects: tasks, revisions, pastes, and other edit-screen-backed objects.
Example fix
// custom record: opt in to transaction timelines
class MyThing extends MyThingDAO
implements PhabricatorApplicationTransactionInterface {
public function getApplicationTransactionEditorHandler() {
return new MyThingTransactionEditor();
}
public function getApplicationTransactionTemplate() {
return new MyThingTransaction();
}
} Defensive patterns
Strategy: type-guard
Validate before calling
// PHP: before calling, resolve the template and check the interface
$object = resolveTemplateObject($viewer, $object_type, $object_identifier);
if (!($object instanceof PhabricatorApplicationTransactionInterface)) {
// route to the application-specific API instead of transaction.search
} Type guard
// PHP
function hasTransactions($object) {
return $object instanceof PhabricatorApplicationTransactionInterface;
} Try / catch
Catch the conduit error client-side, match 'does not implement', and fall back to the owning application's own search/read conduit method for that object type.
Prevention
- Maintain a map of object type -> correct conduit API in client code.
- Assume only edit-screen-backed objects (tasks, revisions, pastes) have transaction timelines.
When it happens
Trigger: Passing objectType USER or a repository object to transaction.search; querying custom objects that store history without application transactions.
Common situations: Assuming every searchable object has a transaction timeline; porting scripts from per-application detail APIs to the generic transaction.search method.
Related errors
- Constraint "phids" to "transaction.search" requires nonempty
- Constraint "authorPHIDs" to "transaction.search" requires no
- Calls to "transaction.search" must specify either an "object
- Calls to "transaction.search" must not specify both an "obje
- In call to "transaction.search", specified "objectType" ("%s
AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21).
Data as JSON: /api/errors/7e87e690419d219f.
Report an issue: GitHub.