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

  1. Use the application's own conduit API for non-transactional objects (e.g. user.search, repository.search).
  2. For custom applications, implement PhabricatorApplicationTransactionInterface and the associated transaction query to opt in.
  3. 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

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


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