The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →For work that may outlast an HTTP request, accept the request, persist a caller-owned job, return 202 Accepted, and let a worker finish it separately. The client checks a status resource and retrieves the result when it is ready. Acceptance is not completion: the job record and follow-up access path are what let the workflow survive a lost connection.
When to use a durable job
A job resource fits work that may not reliably finish within the request budget and whose result can be fetched later. Examples include report generation or a model-backed completion. It decouples execution from the initiating HTTP connection, but it also introduces persisted state, worker operations, and cleanup obligations.
As an Amazon Associate I earn from qualifying purchases.
It is not a universal replacement for request/reply. Keep a synchronous response when work reliably completes within the request budget and an immediate result is part of the contract. A terminal CLI session or unattended overnight batch may not have a user-facing held-connection problem to solve.
Recommended Free Tools
| Interaction | Useful when | Costs or limits |
|---|---|---|
| Synchronous request/reply | Work reliably completes within the request budget and the caller needs the immediate result. | The client connection and request lifecycle remain coupled to processing duration. |
| Durable job plus polling | Work is long-running and callers can make follow-up requests to a status resource. | Requires persisted state, retention and cleanup, polling behavior, and worker operations. |
| Durable job plus push notification | Clients need a timely completion notice and callback or push infrastructure is available. | Adds notification delivery, authorization, and retry concerns. |
| Streaming response | The user needs incremental output as it is generated. | It is a different contract from accepting work and retrieving a completed artifact later. |
| Queue or reply queue | Back-end work and callers need decoupling, or a caller aggregates multiple results. | Adds broker operations and asynchronous result correlation. |
How the job lifecycle should work
- Submit authenticated work with an idempotency key. The key lets a retry identify the original request instead of scheduling duplicate work.
- Validate before acceptance. Check the payload and intended action before starting long-running processing. Microsoft Learn’s Azure Architecture Center states: “The API should validate the request and the action to be performed before it starts the long-running process.” See Asynchronous Request-Reply pattern.
- Deduplicate and create the owned job. Look up a job using the caller identity and idempotency key. If one exists, return its identifier and current state. Otherwise, persist a new job associated with that caller.
- Arrange worker delivery and acknowledge acceptance. Return
202 Acceptedwith a job identifier or aLocationheader pointing to the status resource. ARetry-Afterhint can guide the client’s polling interval. A 202 response says that processing was accepted, not that it succeeded. - Have a worker claim and execute the job. The worker should make state transitions safe against duplicate delivery, call the provider, and store a terminal success or failure with useful structured detail.
- Let the client check status and fetch the artifact. The client polls the authorized status resource, or receives a push notice if the system supports one, then retrieves the result after success. Define how long job and result data remain available.
What belongs in the job record
A job row makes state and result ownership queryable; a queue or worker handoff decouples execution. They solve different parts of the design, so neither should be mistaken for the other. In the proposed FastAPI example, POST /reports creates work and GET /reports/{id} exposes status. Its report_jobs record includes an owner, idempotency key, prompt, result and error fields, timestamps, and a token estimate. A uniqueness constraint on (user_id, idempotency_key) makes the deduplication scope explicit.
#1 Best Overall
The example uses queued, running, succeeded, and failed as status values. They are sample choices, not required standard values. Define the states your clients need, including whether cancellation is supported and what structured error information is safe to expose.
Authorize every read
Authenticate the caller when creating the job, associate the row with that identity, and check ownership on every status and result request. The example returns 404 both for a missing job and for one owned by another user, avoiding a distinction that would disclose another caller’s job. Whatever response policy you choose, do not let possession of a job ID alone grant access.
Rank #2
![Express Schedule Free Employee Scheduling Software [PC/Mac Download]](https://m.media-amazon.com/images/I/41yvuCFIVfS._SL160_.jpg)
- Simple shift planning via an easy drag & drop interface
- Add time-off, sick leave, break entries and holidays
- Email schedules directly to your employees
Scope idempotency to the real caller
A unique key only deduplicates correctly when its scope reflects who made the request. If multiple end users act through one shared service account, using that account as the only scope can collapse distinct users’ requests into one job. Include the appropriate end-user identity or tenant boundary in the deduplication contract.
Make the handoff safe to retry
Persisting a job and publishing work to a broker are separate operations unless the design explicitly makes them atomic. A failure between them can leave a row with no message, or a message whose state is not ready. Consider a transactional outbox where supported, and provide a recovery path for jobs that remain queued without being claimed.
Duplicate delivery is normal enough to design for. A worker can attempt a conditional queued-to-running claim so two deliveries do not execute the same job concurrently. That does not by itself make a provider call or its side effects exactly-once: interruptions and retries still need safe state transitions and provider-specific retry behavior.
The example checks for an existing job before reserving a separate daily inference budget, which supports deduplication on retries. Its budget is estimated from the prompt before the provider responds, and the shown completion path does not reconcile that estimate against actual usage. Budget reservation, job insertion, and broker publication also span separate operations; deployments should decide how to recover from partial failure rather than assume these steps succeed together.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose polling, push, or streaming deliberately
Periodic HTTP polling is appropriate when callbacks are unavailable or long-lived connections are undesirable. Set a reasonable interval, return a useful next-check hint where possible, and avoid having every client poll too aggressively. Long polling can reduce notification delay, but it still holds a connection until data or a timeout and adds connection-management complexity.
If users need real-time or incremental output, choose an interaction that matches that requirement rather than disguising it as a completed-job fetch. Microsoft identifies server-sent events (SSE) for streaming, and also points to WebSockets or SignalR, webhooks, and reply queues for other notification needs. Each option changes delivery, authorization, retry, and client-reconnection behavior.
Operational and data decisions to make
- Retention: Set expiration and cleanup rules for job metadata and artifacts; clients need to know when a result will stop being available.
- Cancellation: Specify whether cancellation is accepted only before a worker claims a job, can interrupt provider work, or is unsupported.
- Errors: Store a stable, structured failure state for clients while keeping sensitive provider diagnostics in appropriately protected operator logs.
- Sensitive inputs: If prompts or request payloads are persisted, the job store becomes sensitive data storage. Apply access controls and retention rules accordingly.
- Recovery: Decide how to find and repair work stranded between persistence, queue publication, worker claim, and result storage.
The article’s proposed implementation is a design slice, not a reported production test or performance benchmark. Its suggested checks—duplicate submissions, worker interruption, provider failure, and cross-user result access—are useful cases to test before relying on the workflow. Its constrained free inference setup is described as a staging seam, not a capacity plan or latency SLO.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
