What causes "No valid object provided for object rule!" in phacility/phabricator?

Confirm the target object still exists and re-pick it from the rule editor's object chooser right before saving.

phacility/phabricator · error · Exception

No valid object provided for object rule!

Error message

No valid object provided for object rule!

What it means

Thrown by HeraldRuleController when creating or editing an object-bound ('object') Herald rule. The controller takes the targetPHID from the request, loads it with PhabricatorObjectQuery requiring BOTH CAN_VIEW and CAN_EDIT capabilities, and throws this plain Exception when executeOne() returns nothing. So the PHID either does not exist, is not visible to the editing user, or is not editable by them.

Source

Thrown at src/applications/herald/controller/HeraldRuleController.php:86

              'content type ("%s").',
              $rule->getRuleType(),
              $rule->getContentType()))
          ->addCancelButton($new_uri);
      }

      if ($rule->isObjectRule()) {
        $rule->setTriggerObjectPHID($request->getStr('targetPHID'));
        $object = id(new PhabricatorObjectQuery())
          ->setViewer($viewer)
          ->withPHIDs(array($rule->getTriggerObjectPHID()))
          ->requireCapabilities(
            array(
              PhabricatorPolicyCapability::CAN_VIEW,
              PhabricatorPolicyCapability::CAN_EDIT,
            ))
          ->executeOne();
        if (!$object) {
          throw new Exception(
            pht('No valid object provided for object rule!'));
        }

        if (!$adapter->canTriggerOnObject($object)) {
          throw new Exception(
            pht('Object is of wrong type for adapter!'));
        }
      }

      $cancel_uri = $this->getApplicationURI();
    }

    if ($rule->isGlobalRule()) {
      $this->requireApplicationCapability(
        HeraldManageGlobalRulesCapability::CAPABILITY);
    }

    $adapter = HeraldAdapter::getAdapterForContentType($rule->getContentType());

View on GitHub (pinned to 5720a38cfe)

Solutions

Confirm the target object still exists and re-pick it from the rule editor's object chooser right before saving.
Verify the acting user has both view AND edit permission on the target object (object rules require CAN_EDIT, not just CAN_VIEW).
Pass the full PHID (e.g. PHID-TASK-abcdef) as targetPHID, not a monogram or ID.
If scripting the request, resolve the name to a PHID first with a PhabricatorObjectQuery (or 'phid.lookup' Conduit API) and use the returned PHID.

Example fix

// before
$rule->setTriggerObjectPHID($request->getStr('targetPHID')); // raw, unchecked

// after — resolve and capability-check the target first
$object = id(new PhabricatorObjectQuery())
  ->setViewer($viewer)
  ->withPHIDs(array($request->getStr('targetPHID')))
  ->requireCapabilities(array(
    PhabricatorPolicyCapability::CAN_VIEW,
    PhabricatorPolicyCapability::CAN_EDIT,
  ))
  ->executeOne();
if (!$object) {
  // show a user-facing validation error instead of throwing
}

Defensive patterns

Strategy: validation

Validate before calling

// Resolve and capability-check the target BEFORE binding it to the rule
$object = id(new PhabricatorObjectQuery())
  ->setViewer($viewer)
  ->withPHIDs(array($target_phid))
  ->requireCapabilities(array(
    PhabricatorPolicyCapability::CAN_VIEW,
    PhabricatorPolicyCapability::CAN_EDIT,
  ))
  ->executeOne();
if (!$object) {
  // render a validation dialog: object missing, invisible, or uneditable
}

Type guard

function isBindableHeraldTarget($viewer, $phid) {
  if (!preg_match('/^PHID-[A-Z]+-/', $phid)) {
    return false; // not even a PHID-shaped string
  }
  return (bool) id(new PhabricatorObjectQuery())
    ->setViewer($viewer)
    ->withPHIDs(array($phid))
    ->requireCapabilities(array(
      PhabricatorPolicyCapability::CAN_VIEW,
      PhabricatorPolicyCapability::CAN_EDIT,
    ))
    ->executeOne();
}

Try / catch

try {
  // controller request handling for object-rule save
} catch (Exception $ex) {
  if (strpos($ex->getMessage(), 'No valid object') !== false) {
    // return a 404/400 dialog telling the user to re-pick the target,
    // instead of an uncaught 500
  }
}

Prevention

Always select the trigger object with the rule editor's chooser immediately before saving.
Remember object rules require CAN_EDIT on the target, not just visibility.
Scripts should resolve names to PHIDs via Conduit phid.lookup and re-verify existence right before the POST.

When it happens

Trigger: POSTing /herald/edit/ (or /herald/new/) for an object rule with a targetPHID that is malformed, refers to a deleted object, or refers to an object the viewer cannot view or edit. Also triggered when the client fails to pass targetPHID at all, since the query then matches nothing.

Common situations: The target object was deleted between page load and rule save; the user lost edit permission on the object (e.g. left the project that grants it); browser bookmarklet/scripts posting a stale PHID; passing a monogram (T123) where a PHID (PHID-TASK-...) is required.

Related errors

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