Request lifecycle
A Stormedo request is the durable unit of work for one outbound HTTP call. It keeps a stable public ID, target definition, timing, retry policy, status, and attempt history.
Acceptance happens before delivery
Section titled “Acceptance happens before delivery”Stormedo returns 202 Accepted after storing the request for durable delivery. The destination does not need to respond before your application can continue.
The request can then wait for its delivery time, run one or more attempts, and reach a final status independently from the publisher process.
Public request statuses
Section titled “Public request statuses”| Status | Meaning |
|---|---|
queued |
Accepted and ready for immediate execution. |
scheduled |
Accepted and waiting for delay or deliver_at. |
delivering |
Delivery has started. An attempt may be in flight, or the request may be waiting for its next retry. |
succeeded |
The destination returned a successful response. |
failed |
Delivery reached a final non-success outcome. |
cancelled |
Cancellation completed before a final delivery outcome. |
succeeded, failed, and cancelled are final statuses.
Attempts belong to the request
Section titled “Attempts belong to the request”An attempt is one outbound HTTP call. Every completed attempt records timing, response or transport outcome, retryability, retry reason, and the next retry time when another attempt is scheduled.
The stable request ID is sent on every attempt in the Stormedo-Request-Id header.
Reads are eventually consistent
Section titled “Reads are eventually consistent”Request list, detail, and attempt APIs can take a short time to show a newly accepted request. The 202 Accepted response confirms that Stormedo accepted it for delivery.
Cancellation preserves history
Section titled “Cancellation preserves history”Cancellation is an action, not deletion. A cancelled request and its completed attempt history remain available for inspection.
Cancellation returns 409 Conflict if the request has already succeeded or failed. Cancelling an already cancelled request returns 200 OK. A 202 cancellation response with cancellation_requested acknowledges the action; that value is not a request lifecycle status. An in-flight attempt may still finish.
Replay creates new work
Section titled “Replay creates new work”Replay does not mutate the original request. It creates a new request with a new ID and records the original request in replayed_from_request_id.
Only succeeded, failed, or cancelled requests can be replayed. Wait for a final status after requesting cancellation. Replay gets a new request ID, so deduplication by request ID alone does not prevent repeating the original business operation. Keep a stable event or business-operation ID in the payload if replays must also be deduplicated.
At-least-once delivery
Section titled “At-least-once delivery”A destination can accept an attempt before Stormedo records the response. If the execution is interrupted during that window, the same request can be attempted again.
Once this lifecycle is familiar, continue with Idempotency guide to make repeated delivery safe for business operations.