Return a Job ID for Work That Outlives a Request

A practical approach

Step 1

Validate and authorize the request before enqueueing. Record a stable job ID and the minimum input needed by the worker.

Step 2

Expose status values with clear meanings and return a result location when complete. Ensure users can only inspect jobs they are allowed to access.

Step 3

Define retry, cancellation and retention behaviour. Make worker execution idempotent so redelivery does not repeat committed side effects.

Worked example

A learner uploads several documents for a knowledge assistant. The API accepts the upload and returns a job identifier. The interface shows parsing, indexing and completion states, while a failed file can be reported separately instead of making the entire operation disappear behind a timeout.

A mistake to avoid

A queue entry alone is not a user-facing job record. Without durable status, the application may know work was accepted but be unable to explain whether it finished.

Try it yourself

Write the response shapes for accepted, processing, partially failed and completed jobs. Restart a test worker mid-job and confirm that the client can still obtain a meaningful status.

Your implementation checklist

• Acceptance is distinct from completion.
• Job status survives restarts.
• Status access is authorized.
• Redelivery does not duplicate effects.