Sume webhook blocked target is never retried; a DNS miss is
A blocked Sume webhook target fails once and is never retried, while a hostname that does not resolve is retried. What each looks like and how to recover.
If a Sume job webhook points at a target the worker considers unsafe, the delivery is marked failed on the first attempt and is never retried. If the hostname simply does not resolve, that counts as a transient error and the worker retries, so the two failures need different fixes.
The difference matters when you debug by waiting. Waiting out the retry window fixes a DNS typo that you corrected in time; it does nothing for a blocked target. The details here come from the delivery code in the repo; the docs describe the delivery statuses and the retry counts.
The two cases side by side
Delivery happens in the worker. Before it connects, it resolves the hostname once and pins the connection to the vetted addresses, so a DNS answer cannot change between the check and the connect.
| Situation | What the worker does |
|---|---|
| Target is localhost, a private or link-local address, or an internal hostname | Status failed, no next attempt, never retried |
| Hostname does not resolve | Transient error, retried |
| Receiver answers non-2xx or times out after 10 s | Retried, up to 10 attempts, 30 s apart |
| Receiver answers a 3xx redirect | Counts as a failed attempt; redirects are not followed |
| Receiver answers any 2xx | Delivered |
Why a blocked target is terminal
Retrying a request to a private address would only repeat the thing the guard exists to stop, so it does not. The status moves to failed immediately rather than to retrying, which is the easiest way to tell the cases apart when you read the job.
How to recover
Fix the URL or the DNS first. Then you have two ways to get the notification you missed.
A practical habit is to test the receiver before you ever submit a paid job. Hit the URL from a machine outside your network with curl and confirm it answers a POST with a 2xx. Then submit a short, cheap job with the webhook set and watch the job's webhook delivery status. If you see failed with no further attempt scheduled, suspect the target rule. If you see retrying, the worker still believes the problem may clear, so check your DNS and your server's logs for the incoming attempts.
- Call POST /v1/jobs/{id}/webhook/redeliver (needs the jobs:write scope). It sends with a fresh timestamp and does not consume one of the 10 attempts.
- Or read GET /v1/jobs/{id} and take the result from the job record, which does not depend on the webhook at all.
Tradeoffs
Redelivery depends on you noticing. Pair the webhook with a slow reconciliation poll for any job you have not heard about, so a blocked or exhausted delivery never leaves work sitting unseen.
Sources
Related posts
More in Developers
- Sume webhook_url with :8443 is rejected: HTTPS default port only
Sume rejects any webhook_url with an explicit port such as :8443. Use the default HTTPS port, or poll instead. What the check accepts, and where it runs.
- Sume webhook hostname with a private DNS answer is blocked entirely
If any A or AAAA answer for your Sume webhook_url hostname is private, the whole target is blocked. How the resolve-once check works and how to debug it.
- What to log from a Sume MCP agent: ids and status, never signed URLs
Log request ids, job ids when needed, high-level status and sanitized media metadata. Keep API keys, signed URLs, raw private media URLs and transcripts out.
- Which AI video model makes a 25-second clip? Duration check in Python
Only some Sume video models accept 25 seconds in one request. See each model's duration range and filter a target length in a few lines of runnable Python.
Written by Sume