What Does Durable Execution Guarantee, and Where Does It Stop?

Durable execution guarantees that a workflow's completed steps survive a crash and do not run again, so during a failure or restart, the workflow picks up from that last recorded step. It does not guarantee that a step runs exactly once and therefore it won't mitigate bad business logic.

Think of a delivery company with ten packages to deliver that day. The driver successfully delivers four and records each one in their delivery log, but on the way to the fifth delivery, their vehicle breaks down. A replacement driver is dispatched to take over. They don't need to start from the first delivery; they know which four packages have already been delivered because it's in the log, and they can continue with the remaining six.

In Dapr Workflow, that log is the workflow history. The workflow can safely replay, and for each completed activity, the engine returns the stored result instead of scheduling it again. If the node hosting a workflow crashes, a reminder reactivates it and execution carries on. Durable timers survive restarts too, whether the wait is minutes or months.

The durable execution guarantees stop at the last entry. An activity that was running when the process died has no completed entry, so it runs again. The Dapr docs say each activity executes at least once and recommend idempotent activity logic. For a payment or an email, that means an idempotency key or a check before you act.

Durable execution protects your progress, not your business logic. If there's a bug in your workflow, replay won't fix it. It'll just carry on making the same mistake.

In practice, treat the workflow history as the guarantee and every side effect as your responsibility to handle.

Diagrid's FAQ covers the limits in more detail: https://www.diagrid.io/faq/durable-execution