Checklist
Follow an accepted job to its actual completion state
Accepted is a place in the queue, not a certificate of completion.
When it fits
- An interface reports that a request was accepted, while the requested change happens later.
When to avoid it
- Do not poll without bounds or treat disappearance of a job as success. Some systems retain results only briefly, so capture evidence through the supported route.
Checklist
- Save the job identifier and the receiver's status-check route.
- Follow the documented polling or notification policy, including failure and expiry states.
- Confirm the relevant destination result before marking the business task complete.
Why it matters
Use the operation identifier and documented status route to follow asynchronous work. Separate acceptance, processing and terminal outcomes in the report. Then check the business result that matters; an interface can finish while a downstream dependency is still unresolved.
An example
An upload returns an accepted response. The task remains in progress until its status and destination checks confirm the requested records were applied.
Check your result
The completion message cites a terminal operation result and the required business check.
Keep this limit in mind
- Do not poll without bounds or treat disappearance of a job as success. Some systems retain results only briefly, so capture evidence through the supported route.
Connected ideas
Useful withMake every selected record end in an explicit status bucketCompare with
Treat a timeout as an unknown outcome before repeating the action
Evidence and sources
Supports
The asynchronous request-reply pattern can acknowledge acceptance with HTTP 202 while exposing a separate route for checking later completion.
The operation's documented completion state may still differ from downstream business readiness.
Asynchronous Request-Reply pattern · Solution