Let useful work survive interruption

A process is temporary. Useful work often lasts longer: an order waits for approval, an import pauses for a provider, an agent waits for a tool result. Durable execution gives that work a recorded place to continue.

Think of a service with a notebook. It records accepted work and the results it must remember. A later process opens the notebook and reconstructs the relevant state. The notebook is a mental model for the node’s durable history, not a promise that every external action and log write form one atomic transaction.

What persists

Durable actors preserve state and progress under the runtime’s persistence contract. Workflows preserve supported continuations and waits. Recorded effect outcomes connect a run’s progress to interactions beyond the computation.

The state directory holds more than the latest value shown by an inspection command. It includes history, saved state and retained code required by recovery. Treat it as a whole node when planning storage and backup.

Reopening is a concrete first result

The first actor tutorial uses separate processes to create, update and read a counter. The count survives because each command reopens the same state directory.

That proves a useful behaviour in the example. It is different from injecting a crash at every write boundary, losing a disk or testing a network partition. Qualification must match the failure you intend to tolerate.

Recovery and external delivery are separate

Suppose a provider accepts a payment but the connection closes before the caller records the response. A durable runtime can preserve the local state it knows. It cannot infer the provider’s outcome from silence alone.

The integration needs an idempotency key, a query for the existing result, reconciliation or another explicit delivery contract. Blind retry may duplicate an action. Treat an ambiguous outcome as a state that needs resolution.

Code changes need compatible state

Changing a struct does not silently reinterpret an existing actor’s saved values. A schema change needs an explicit compatibility decision and, when necessary, a conversion or migration plan.

Likewise, a running operation has a relationship to the code that admitted it. A local watch loop selecting a new version does not authorize arbitrary reinterpretation of every in-flight operation.

Know the recovery boundary

Local persistence does not imply replicated storage or recovery after all local copies are lost. Cross-node execution and managed operations are separate capabilities. Your storage, backup and restore procedures remain part of the deployed system.

Use durability to make progress explicit, then test the failures that matter to your workload. Handling external effects shows how to design the most common ambiguous boundary.