Build a queue-backed task with visible status

Long work should not leave an HTTP connection open indefinitely. Accept a task, return its identity and expose a state machine the client can poll or receive by callback.

Reject an invalid transition

The engineering foundations lab checks three fixture transitions.

from engineering_cases import queue_status_case

result = queue_status_case()
assert result["invalid_indices"] == [2]
assert result["checked"][0]["allowed"] is True
assert result["checked"][2]["allowed"] is False
assert result["external_queue"] is False

Moving a succeeded task back to running is invalid. No broker runs.

Return 202 with task ID and status URL after durable enqueue. Store tenant, idempotency key, created/updated timestamps, attempt, progress where meaningful, result reference and stable error. Authenticate status access so IDs cannot cross tenants.

Workers claim tasks atomically, heartbeat leases, bound retries and make side effects idempotent. Define cancellation and retention. Status should distinguish failed from queued-for-retry; clients should not guess from missing output.

The FDE for Freshers course introduces background jobs before durable workflow and agent patterns.

Exercise

Implement an in-memory queue and status API, then kill a worker mid-task. Prove the lease recovers without duplicating the result.

Continue learning

This article is part of the FDE engineering foundations sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in JSON schema validation at an API boundary.
• Continue with Choose a data structure for a practical engineering problem.

Reference: FastAPI background-task documentation.