phacility/phabricator · error · Exception

This object ("%s") has more than %s transactions in its most

Error message

This object ("%s") has more than %s transactions in its most recent transaction group; this is too many.

What it means

Thrown by HeraldTestConsoleController::loadAppliedTransactions() while building a dry-run test in the Herald test console. It walks the object's transactions (skipping Herald-applied ones) grouped by transaction group ID, and hard-caps the most recent group at $hard_limit = 1000. If a single transaction group exceeds 1000 entries, iteration is aborted with this exception naming the object PHID and the limit.

Source

Thrown at src/applications/herald/controller/HeraldTestConsoleController.php:308

        if ($recent_id === null) {
          // If the first transaction has no group ID, it is likely an older
          // transaction from before the introduction of group IDs. In this
          // case, select only the most recent transaction and bail out.
          $applied[] = $xaction;
          break;
        }
      }

      // If this transaction is from a different transaction group, we've
      // found all the transactions applied in the most recent group.
      if ($group_id !== $recent_id) {
        break;
      }

      $applied[] = $xaction;

      if (count($applied) > $hard_limit) {
        throw new Exception(
          pht(
            'This object ("%s") has more than %s transactions in its most '.
            'recent transaction group; this is too many.',
            $object->getPHID(),
            new PhutilNumber($hard_limit)));
      }
    }

    return $applied;

  }

}

View on GitHub (pinned to 5720a38cfe)

Solutions

  1. Pick a healthier object of the same type for the dry run — the limit protects the console from pathological groups, not the object itself.
  2. If the object is legitimately huge, test the rules from the CLI instead: bin/herald test --object <monogram> --type <content type>, which does not load applied transactions this way.
  3. Fix the producer: batch your edits into smaller transaction groups or fewer, larger transactions so no single group approaches 1000.
  4. Raise the hard limit locally only if you accept the memory/time cost (edit $hard_limit in HeraldTestConsoleController), then re-run and archive/delete what you can.

Example fix

// before — one transaction per object, all sharing a group id
foreach ($phids as $phid) {
  apply_xaction($parent, $phid, $group_id); // 1000+ entries -> error 831
}

// after — chunk the work into distinct groups
foreach (array_chunk($phids, 100) as $chunk) {
  apply_batch($parent, $chunk); // each batch = its own transaction group
}
Defensive patterns

Strategy: try-catch

Try / catch

try {
  $xactions = $this->loadAppliedTransactions($object);
} catch (Exception $ex) {
  if (strpos($ex->getMessage(), 'transactions in its most recent') !== false) {
    // fall back to running rules without 'applied transactions' context,
    // or direct the user to a smaller object
  }
}

Prevention

When it happens

Trigger: Opening /herald/test/ for an object (e.g. a Maniphest task or revision) whose most recent transaction group contains more than 1000 transactions — typically produced by a bulk editor (batch edit of thousands of subtasks), a runaway script, or an import that created a huge single-group edit.

Common situations: Bulk-modifying thousands of objects that all transaction onto one parent; a loop in custom code applying transactions one-by-one within the same group; data imports replayed as a single grouped edit. The test console is a diagnostic page, so this surfaces exactly when admins try to dry-run rules against pathological objects.

Related errors


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