phacility/phabricator · error · Exception
Webhook request ("%s", to "%s") failed (%s / %s). The reques
Error message
Webhook request ("%s", to "%s") failed (%s / %s). The request will be retried. What it means
After a webhook call times out or errors, if the request's retry mode is RETRY_FOREVER the worker records RESULT_FAIL, saves the request, and throws a plain Exception -- which makes the task daemon retry it later with backoff. This is the designed failure path for receivers that are temporarily down; it is transient by construction.
Source
Thrown at src/applications/herald/worker/HeraldWebhookWorker.php:219
}
$error_code = $status->getStatusCode();
$request
->setErrorType($error_type)
->setErrorCode($error_code)
->setLastRequestEpoch(PhabricatorTime::getNow());
$retry_forever = HeraldWebhookRequest::RETRY_FOREVER;
if ($status->isTimeout() || $status->isError()) {
$should_retry = ($request->getRetryMode() === $retry_forever);
$request
->setLastRequestResult(HeraldWebhookRequest::RESULT_FAIL);
if ($should_retry) {
$request->save();
throw new Exception(
pht(
'Webhook request ("%s", to "%s") failed (%s / %s). The request '.
'will be retried.',
$request->getPHID(),
$uri,
$error_type,
$error_code));
} else {
$request
->setStatus(HeraldWebhookRequest::STATUS_FAILED)
->save();
throw new PhabricatorWorkerPermanentFailureException(
pht(
'Webhook request ("%s", to "%s") failed (%s / %s). The request '.
'will not be retried.',
$request->getPHID(),
$uri,View on GitHub (pinned to 5720a38cfe)
Solutions
- Fix the receiving endpoint -- check its logs for the failing request from the Phabricator host.
- Verify the network path (DNS, firewall, TLS) from the Phabricator server, not from your workstation.
- No Phabricator-side action is required: once the endpoint recovers, the retries will succeed and the request flips to SENT.
- If the retry flood is unwanted, change the hook's retry policy away from retry-forever.
Defensive patterns
Strategy: retry
Validate before calling
// Probing a receiver before enabling retry-forever:
PhabricatorEnv::requireValidRemoteURIForFetch($uri, array('http', 'https'));
// then a cheap GET/HEAD from the Phabricator host confirms reachability Try / catch
// The worker already retries with backoff; in adjacent tooling mirror that:
try {
deliver();
} catch (Exception $ex) {
// transient: schedule retry with exponential backoff, cap concurrency
scheduleRetry($ex);
} Prevention
- Set retry-forever on hooks pointing at services with occasional deploys; use limited retries for strict ones.
- Watch request RESULT_FAIL counts as an early signal that a receiver is down.
- Keep receiver timeouts shorter than the worker task lease so retries are not duplicated.
When it happens
Trigger: The receiver returned 5xx, refused the connection, or timed out, and the hook is configured to retry forever; each retry that still fails rethrows this exception.
Common situations: Target service restarting or deploying; slow endpoint exceeding the HTTP timeout; network blips between Phabricator and the receiver.
Related errors
- Unable to load webhook request ("%s"). It may have been garb
- Webhook request ("%s") is not in "%s" status (actual status
- Associated hook ("%s") for webhook request ("%s") is disable
- Unable to load object ("%s") for webhook request ("%s").
- Webhook request ("%s", to "%s") failed (%s / %s). The reques
AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21).
Data as JSON: /api/errors/66ce8f088e78fd7f.
Report an issue: GitHub.