2026-09-27 · 5 min read · Rahul Chitturi
- http
- async
- reliability
A 202 Accepted response means the server accepted a request for processing but has not completed it. It does not promise success, and HTTP has no later automatic response that updates the original request.
Clients get stuck when the response omits a stable status resource, polling ignores server timing, jobs expire without a terminal record, or retries create several copies of the same operation.
Write down the asynchronous contract
Capture the submission method, idempotency key, 202 body, Location or documented status link, retry guidance, authorization context, state vocabulary, result link, error shape, expiry, and cancellation semantics.
- Use an opaque, stable job identifier.
- Authorize every status and result request.
- Define terminal success and failure states.
- Bound status retention after completion.
Control polling and duplicate submissions
Respect Retry-After when the contract uses it, otherwise apply a documented interval with bounded exponential backoff and jitter. Stop on terminal state, expiry, cancellation, or a client deadline rather than polling forever.
Persist the outcome under a scoped idempotency key before acknowledging duplicate submissions. A transport timeout can happen after job creation, so clients need a safe way to recover the existing job instead of starting another.
Exercise the complete lifecycle
Use Flashman's URL tool for status links, JSON formatter for state payloads, timestamp converter for retry and expiry windows, and UUID generator for synthetic operation identifiers.
Test fast and slow completion, rejection after acceptance, duplicate submission, worker retry, polling bursts, authorization loss, cancellation races, expired jobs, result cleanup, service restart, malformed links, and inaccessible terminal errors.