phacility/phabricator · error · PhutilArgumentUsageException

Work has already started on job "%s". Jobs can not be reconf

Error message

Work has already started on job "%s". Jobs can not be reconfigured after they have been started.

What it means

Bulk jobs can only be reconfigured while awaiting confirmation (STATUS_CONFIRM); once work starts, the mail/notification settings are frozen. The workflow first returns success if the job is already silent (getIsSilent), then rejects any status other than confirm with this exception. This prevents changing notification behavior mid-run, which subscribers could observe as inconsistent.

Source

Thrown at src/applications/transactions/bulk/management/PhabricatorBulkManagementMakeSilentWorkflow.php:52

      ->setViewer($viewer)
      ->withIDs(array($id))
      ->executeOne();
    if (!$job) {
      throw new PhutilArgumentUsageException(
        pht(
          'Unable to load bulk job with ID "%s".',
          $id));
    }

    if ($job->getIsSilent()) {
      echo tsprintf(
        "%s\n",
        pht('This job is already configured to run silently.'));
      return 0;
    }

    if ($job->getStatus() !== PhabricatorWorkerBulkJob::STATUS_CONFIRM) {
      throw new PhutilArgumentUsageException(
        pht(
          'Work has already started on job "%s". Jobs can not be '.
          'reconfigured after they have been started.',
          $id));
    }

    $job
      ->setIsSilent(true)
      ->save();

    echo tsprintf(
      "%s\n",
      pht(
        'Configured job "%s" to run silently.',
        $id));

    return 0;
  }

View on GitHub (pinned to 5720a38cfe)

Solutions

1. Silence the job before confirming it in the UI — that confirmation window is the only opportunity.
2. If work already started, let it finish and send a follow-up notice; the setting cannot be changed retroactively.
3. For future jobs, have the actor be a bot account or disable mail globally so notifications are naturally suppressed.

Example fix

# wrong order: confirm first, then try to silence
bin/bulk make-silent --id 123   # fails: work already started
# right order: silence while the job still awaits confirmation
bin/bulk make-silent --id 123   # then confirm the job in the web UI

# only attempt to silence jobs still awaiting confirmation
status=$(get_bulk_job_status "$JOB_ID")
if [[ "$status" != "confirm" ]]; then
  echo "job $JOB_ID is '$status'; can only be silenced while awaiting confirmation" >&2; exit 2
fi

// inside Phabricator tooling
function isSilenceable(PhabricatorWorkerBulkJob $job) {
  return $job->getStatus() === PhabricatorWorkerBulkJob::STATUS_CONFIRM
    && !$job->getIsSilent();
}

Catch PhutilArgumentUsageException, match 'Work has already started', and treat it as a process signal: the silence window was missed, escalate to the operator instead of retrying.

When it happens

Trigger: Calling make-silent on a job that is already running, waiting, or complete; racing the daemon workers that pick the job up right after it was confirmed.

Common situations: An operator notices a loud bulk edit only after approving it; automation that tries to silence jobs after the fact.

Related errors

• Use "--output <path>" to specify an output file, or "--outpu
• Use "--id" to choose a bulk job to make silent.
• Unable to load bulk job with ID "%s".
• Request parameter "%s" is not formatted properly. Expected a
• Request parameter "%s" is not formatted properly. Expected a

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