Background Job
A background job is a task the server runs separately from the page or API reply that may start it. The reply can finish before the job does.
accepted request -> persisted job ID -> runner attempt -> terminal result; bounded retryGET /jobs/job_482accepted request -> persisted job ID -> runner attempt -> terminal result; bounded retryJOBAnother example
A report request creates job `report-204` and replies with a status link. A Kubernetes Job runs the report until it succeeds or reaches its retry limit, records that final state, and stops.
Main parts
- 01Job ID and saved input
- 02Accepted or queued state
- 03Runner and attempt
- 04Progress or heartbeat
- 05Success or failure state
- 06Result and recovery path
Use it when
Use a background job when slow work can finish after the person gets a reply. Save its input, identity, status, and final result.
Do not use it when
Do not use it when the reply needs the result now. A runner may try a failed job again. Add a safety rule before repeating charges, emails, or other effects.
Name used in code
accepted request -> persisted job ID -> runner attempt -> terminal result; bounded retry Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Background Job for this system while keeping data correct, secure, and easy to operate. User context: A report request creates job `report-204` and replies with a status link. A Kubernetes Job runs the report until it succeeds or reaches its retry limit, records that final state, and stops. Technical concept or control: Background Job. Why it fits: Use a background job when slow work can finish after the person gets a reply. Save its input, identity, status, and final result. Do not use it when: Do not use it when the reply needs the result now. A runner may try a failed job again. Add a safety rule before repeating charges, emails, or other effects. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Background Job. Definition: A background job is a task the server runs separately from the page or API reply that may start it. The reply can finish before the job does. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.