DEV Community: Joni Collinge

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

Joni Collinge — Tue, 03 Nov 2026 10:11:41 +0000

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

Why Does a Workflow That Runs Forever Need Continue-as-New?

Joni Collinge — Thu, 22 Oct 2026 08:40:33 +0000

Short answer: a Dapr workflow's history only grows, and continue-as-new is the operation that starts it again with an empty one.

The hard part is that the history is also how the workflow survives. Dapr Workflow keeps an append-only log of every step and replays it to rebuild state after a restart. For a ten-step workflow that costs nothing. For a monitoring workflow written as a while (true) loop that checks something every five minutes, every cycle adds entries, and every replay reads all of them.

Continue-as-new restarts the workflow with a new input and a fresh history. The Dapr docs recommend it for "eternal workflows" such as monitoring agents. The loop body becomes one cycle: run the check, wait on a durable timer, then continue-as-new with whatever the next cycle needs to know.

Two things catch people out.

Pass everything forward. The old history is discarded, so state you leave out of the new input is gone.

Await your work before you continue. Continue-as-new restarts immediately and drops any activities, timers or child workflows that were started but not awaited.

A long-lived agent that wakes, checks, acts and sleeps fits this shape well. It is a monitoring workflow with a model call in the middle.

Docs on continue-as-new and history size: https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-features-concepts/

How durable agents use workflow history: https://www.diagrid.io/learn/durable-agents

Control Plane vs. Data Plane: Who owns what?

Joni Collinge — Mon, 12 Oct 2026 13:49:46 +0000

A lot of confusion when evaluating cloud platforms comes from the lack of clarity surrounding two terms: control plane and data plane.

In reality, the distinction is simple.

The data plane handles runtime execution: processing your requests, running workflows and agents, and interacting with application state and dependencies.

The control plane manages the platform: provisioning resources, distributing configuration, managing upgrades and exposing operational controls.

Why does this matter?

“Where does my data go?” Understand what the data plane processes, where it runs, what it stores and what crosses the boundary to the vendor.

“What happens when the vendor has an outage?” Understand whether the data plane can continue running independently if the control plane becomes unavailable. A management API going down shouldn't necessarily mean your running workflows stop.

“What does BYOC actually mean?” It depends on the architecture. Your data plane might run in your cloud account while the vendor operates the control plane remotely. Or you might operate both yourself. Those are materially different deployment models.

You don't need to understand every detail of a vendor's internals. You need one clear diagram showing both planes, where they run, and what crosses the boundary between them.

If a vendor can't explain that clearly, it's worth asking why.

Here's how we've mapped it across all five of Diagrid Catalyst's deployment models: https://www.diagrid.io/blog/catalyst-deployment-models