Django’s task interface still needs an execution owner
Django 6.0 defines and enqueues tasks while execution stays external. Choose persistence, recovery and operational ownership before promising delivery.
By 
Paul. Architecture and infrastructure
Defining a task and arranging for it to run are separate responsibilities. Django 6.0 gives application code a standard task interface, while a production deployment still needs an execution backend and people responsible for operating it. Adopting the interface is a design decision about how code requests work. It does not by itself decide where the work survives, what happens after failure or who investigates unfinished tasks.
That boundary is useful rather than disappointing. An application can express a task without embedding every operating detail in the function that requests it. The team can then choose those details explicitly. Trouble begins when a convenient method name becomes a promise of durable delivery that nobody checked against the configured backend.
What shipped on 3 December
The Django 6.0 announcement dated 3 December 2025 includes background tasks. The release notes describe task definition, validation, queuing and result handling, with execution left to external infrastructure. Its two built-in backends are primarily for development and testing. Those are the release’s boundaries, not a bundled production worker service.
The maintained 6.0 task guide, consulted in November 2026, says the default ImmediateBackend runs tasks immediately rather than in the background. DummyBackend does not execute them and leaves results in READY. Neither supplies a default durable production queue. This guide is current documentation for that version line, not a frozen copy of the release-day page.
The distinction changes how a demonstration should be interpreted. A task returning a result under immediate execution can establish that its function ran in that configuration. It does not exercise a separate worker, persistence across a process restart or recovery after lost execution. No implementation test was performed for this article; the operating questions below are proposed acceptance criteria.
Choose the backend contract deliberately
Start with what losing the work would mean. A disposable calculation and an obligation to send an approved document have different consequences. Decide whether the application needs a persistent record of pending work, how long that record remains available and what evidence marks completion. The task interface supplies a place to express the request; the chosen deployment must satisfy the required lifetime.
Record the boundary between accepting a request and making it available to workers. A database change and an enqueue operation can involve different systems. If one succeeds and the other fails, the business may have recorded an obligation without scheduling its execution. The existence of a framework API does not establish atomicity across those systems. The selected backend and application design need an explicit answer.
A transaction-aware enqueue policy can address some timing problems, but its precise guarantee deserves inspection. Scheduling after commit avoids asking a worker to read uncommitted application data; it does not automatically prove that every committed obligation reached durable storage. Describe the failure being prevented before choosing a mechanism. Avoid compressing several different guarantees into the phrase “transaction safe”.
Results need a business interpretation
A worker can finish its function while the business process remains incomplete. A successful request to another service may mean that service accepted work, rather than that the final document reached its recipient. Choose task names and visible statuses that preserve that distinction. Otherwise operators may see technical success while customers still wait for the promised outcome.
Define what an operator can inspect when progress stops. A useful record connects the business operation to the task request and the attempt that handled it. It should distinguish pending work from failed work and from work whose outcome is uncertain. That distinction matters when deciding whether another attempt would help or might duplicate an external effect.
Retries need the same care. A temporary dependency failure can justify another attempt. Repeating an operation after an ambiguous timeout may instead repeat a completed effect. Determine which operations can safely be repeated, which need a stable business identifier and which require reconciliation. These are requirements to evaluate in a backend and application, not claims that Django implements a universal retry policy.
Assign responsibility across the boundary
The person maintaining application functions and the person operating workers may be the same person, but the duties remain different. Someone needs to notice an unavailable worker, an ageing backlog or a permanently failing task. Someone also needs authority to pause execution and decide when replay is appropriate. A queue can preserve work while nobody is available to resolve it.
Include deployment compatibility in that responsibility. Workers can encounter tasks requested by application code from another version during rollout. Agree how long old task definitions remain understood and what happens to pending work when a definition changes. A standard interface helps organise the boundary; it cannot choose the product’s compatibility policy.
The strongest counterargument is that a small application may have little background work and can reasonably start with immediate execution. That can be an honest, simpler choice when request latency and failure consequences are acceptable. It should be described as that choice. The mistake is presenting it to stakeholders as a separately operated durable task system because the same function might later run through one.
Use the interface to make decisions visible
For an existing application, a working queue is not automatically a migration problem. Compare the value of the standard interface with the cost of adapting task definitions, results and operational procedures. Retaining a proven backend can be sensible. A migration needs evidence that the selected combination preserves the business obligations, not merely that the decorator imports.
For software maintenance, put the configured backend, persistence expectations and recovery owner beside the task inventory. State what acceptance and completion mean for each consequential operation. Django’s interface can then provide a consistent way to request work while the deployment supplies an explicit execution contract that the team can inspect and operate.