phacility/phabricator · error · PhutilArgumentUsageException

No task with ID "%s" matches the constraints!

Error message

No task with ID "%s" matches the constraints!

What it means

Thrown after task selection when an explicit `--id` value did not survive the query: the workflow merges active and archived results (honoring `--active`/`--archived` and all other constraints) and verifies every requested ID is present. Unlike other constraints, where an empty selection is acceptable, explicitly requested IDs must resolve or the command aborts. The message interpolates the first missing ID.

Source

Thrown at src/infrastructure/daemon/workers/management/PhabricatorWorkerManagementWorkflow.php:223

    if ($active) {
      $archive_tasks = array();
    } else {
      $archive_tasks = $archive_query->execute();
    }

    $tasks =
      mpull($active_tasks, null, 'getID') +
      mpull($archive_tasks, null, 'getID');

    if ($limit) {
      $tasks = array_slice($tasks, 0, $limit, $preserve_keys = true);
    }


    if ($ids) {
      foreach ($ids as $id) {
        if (empty($tasks[$id])) {
          throw new PhutilArgumentUsageException(
            pht('No task with ID "%s" matches the constraints!', $id));
        }
      }
    }

    // We check that IDs are valid, but for all other constraints it is
    // acceptable to select no tasks to act upon.

    // When we lock tasks properly, this gets populated as a side effect. Just
    // fake it when doing manual CLI stuff. This makes sure CLI yields have
    // their expires times set properly.
    foreach ($tasks as $task) {
      if ($task instanceof PhabricatorWorkerActiveTask) {
        $task->setServerTime(PhabricatorTime::getNow());
      }
    }

    // If the user specified one or more "--id" flags, process the tasks in

View on GitHub (pinned to 5720a38cfe)

Solutions

  1. Confirm the task exists: `./bin/worker show --id <id>` or query both tables without status flags
  2. Drop the contradicting constraint (run with just `--id <id>`, no `--active`/`--archived`/`--class`)
  3. If the ID is simply gone, the task was deleted or never existed; obtain the current ID from the worker logs or `worker_archive` table

Example fix

# before (task 42 already archived)
./bin/worker retry --id 42 --active

# after
./bin/worker retry --id 42
Defensive patterns

Strategy: validation

Validate before calling

// Pre-check the task exists in either table with no status constraint
$exists = shell_exec(
  sprintf('./bin/worker show --id %d 2>&1', $task_id));
if (strpos($exists, 'No task with ID') !== false) {
  // task gone or filtered: refresh task list before acting
}

Try / catch

// PHP script invoking the CLI
$exit = 0;
passthru('./bin/worker retry --id 42', $exit);
if ($exit !== 0) {
  // re-query the task and handle not-found/archived-state cases
}

Prevention

When it happens

Trigger: `./bin/worker retry --id 999999` (no such task); `--id 42 --archived` when task 42 is still active; combining `--id 42 --class OtherClass` so the class filter excludes task 42; `--id 42 --active` when 42 already completed and moved to the archive table.

Common situations: Task ID copied from stale output (the task archived or was garbage-collected between observation and action); scripts replaying recorded IDs after a queue drain; mixing an ID with a class or status filter that contradicts the task's actual state.

Related errors


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