The value of Durable Task lies not in replacing every background worker, message queue, or database, but in organizing processes that run for a long time, pause while waiting for an external event, or may be interrupted after part of their steps have been executed. The .NET blog presents five practical examples using the Durable Task .NET SDK version 1.26.0 with Durable Task Scheduler, emphasizing that the tool preserves the orchestration history and does not restore a suspended CLR execution stack.
The central idea is to separate what the workflow engine orchestrates from what remains the application's responsibility. Durable Task can save progress points, wait without keeping a busy execution thread, and replay orchestrator code based on recorded results. However, it does not determine user permissions, guarantee exactly-once execution of external side effects, or determine on its own which resources are safe to delete or whether a payment has actually arrived.
Human Approval Does Not Mean Stopping the Worker
In invoice processing, each invoice can run in its own independent sub-orchestration. Invoices that do not require review continue through the process, while an invoice requiring human approval waits for an external event and a durable timeout. If the worker stops, another worker can replay the orchestrator and return to the waiting point instead of rebuilding the state manually.
However, the approval event is merely a signal. A documented endpoint must atomically record the final decision in the application store before sending the signal, and the accounting step must verify a stable deployment identity and an immutable request fingerprint. If the accounting entry is accepted and the activity confirmation is then lost, the Durable Task history alone is not enough to prevent duplication; a reconciliation protocol with the accounting system is required.
Provisioning an Azure Environment: Where Does ARM's Role End?
The article explains that ARM and Bicep may be sufficient for deploying specific resources, as they provide dependency ordering, parallel execution, and reapplication of the desired state with stable identities. Therefore, adding Durable Task is not justified for rebuilding a deployment plan that ARM already provides.
The benefit appears when the process extends beyond resource deployment to accepting a tenant request, reporting progress to it, waiting for readiness, and then activating the tenant. The example proposes saving the provisioning request and its identifiers in the application database with an outbox, then using an orchestration that connects the network, database, storage, application, DNS, and readiness-check stages. Azure operations themselves still require operation logs, stable identities, and reconciliation when responses are lost.
The article warns against treating compensation as an undo button. Azure may still be creating a database after storage has failed. Therefore, the old attempt must be prevented from starting new operations, previously submitted operations must be checked, and resources owned exclusively by the attempt must be deleted only after confirming that no delayed operations could recreate them. If the state or ownership cannot be proven, the safe result is NeedsIntervention, not speculative deletion.
A Payment Timeout Is Not a Decline
In a subscription cycle, the payment provider's response may disappear after the operation has been accepted. Retrying immediately may impose a duplicate charge, while treating it as declined may send a misleading alert. The example proposes associating each payment cycle with a cycle identifier and a stable payment key, then using durable timers, callbacks, periodic checks, and a defined grace period.
The payment ledger remains the authoritative source for the Unknown, Pending, Declined, Paid, and NotCharged states. The cycle does not move to the next one until receipt confirmation is obtained and the current cycle is closed. If the timeout expires while the state remains unresolved, the result is NeedsReconciliation rather than assuming that the payment succeeded or failed.
Late Events Need Protection at the Destination
When updating a search index for news articles, version 12 may arrive after version 13, or indexing operations may complete in the opposite order. A durable entity can store the highest version seen and serialize updates to its counters, but it does not lock the external index or prevent two requests from writing in parallel.
Therefore, the destination itself must enforce an atomic version barrier that rejects a write of an older version after a newer version has been committed. The system also needs a reliable inbox, a continuation dispatcher, and periodic reconciliation with the source. Even a single-identifier orchestrator pattern does not provide an exactly-once execution guarantee for external side effects.
What Does This Mean for AI Agents?
In an incident assistant workflow, the process requires saving the specific model proposal, waiting for an engineer's approval, and then executing the approved tool after a possible failure. The value lies in recovering the approval path and the same decision, not in generating a new proposal after every replay. The proposal's identity, the tool's authorization, and preventing an old or duplicate request from being executed remain the application's responsibilities.
The practical conclusion from the five examples is that Durable Task is suitable when preserving “what will happen next” becomes a system in its own right. If the application already has queues, timers, and clear reconciliation records, or if the external system provides reliable orchestration such as ARM, the framework may add more complexity than value. All the examples also depend on explicit external boundaries: an authoritative record, an idempotency key, a version barrier, an outbox, or a reconciliation protocol.