Runtime
Durable execution is more than retrying a function
Retries matter, but durable workflows also need stable history, immutable definitions, honest recovery, and a clear answer when an external effect may have happened.
A retry loop can run a function again. It cannot, by itself, tell an operator which definition ran, which decisions were made, whether a wait survived a restart, or whether an external side effect already happened. Durable execution begins with a trustworthy history.
Execution needs one source of truth
WOML records append-only run events and derives context, inspection, and terminal presentation from that history. A run binds to the exact compiled workflow and module artifacts active when it was admitted. Editing the source changes future runs; it does not silently change the program an existing run is recovering.
This matters when work lasts longer than one process. A durable wait, approval, retry delay, or child workflow call can release capacity and continue later without relying on an in-memory object as the authority.
Retries need stable identity
A WOML step can declare bounded attempts and fixed or exponential backoff. Each attempt receives attempt.number, attempt.maxAttempts, and a stable idempotency key for the logical step and run.
The key becomes useful only when an external API explicitly supports idempotency. WOML does not turn an arbitrary effect into exactly-once execution by naming it.
<step
id="chargePayment"
name="Charge payment"
retry="3"
retry-backoff="exponential"
retry-delay="1s"
retry-max-delay="8s"
>
<script>
return services.http.request({
url: "https://payments.example.com/charges",
method: "POST",
json: context.payload,
idempotency: {
header: "Idempotency-Key",
value: attempt.idempotencyKey
}
}, { name: "create-charge" });
</script>
</step>Ambiguity is a real runtime state
Suppose a process sends a request, the remote system commits it, and the local process stops before recording the result. A restart proves that the attempt began, but not whether the effect happened. Blindly retrying may duplicate the effect; pretending it failed may be equally wrong.
WOML fails an uncertain effect closed unless a reviewed capability has durable proof that it can reattach safely. For remote execution, an operator can inspect the real system and record an audited reconciliation decision instead of letting the runtime guess.
Durability is not the promise that nothing uncertain happens. It is the promise that uncertainty is recorded and handled honestly.
Reliability lives beside the workflow
Concurrency, rolling rate limits, deadlines, durable queues, retries, waits, locks, compensation, cleanup, and human approvals are part of the executable workflow contract. They are not deployment notes that an operator must remember to recreate later.
The CLI completes the operating loop: check source, run workflows, inspect runtime health, list and examine runs, follow output, cancel work, recover verified-safe attempts, back up state, and apply retention. Durable execution becomes useful when the history and the controls are available to the people responsible for the system.
Topics
- durable execution
- retries
- recovery
- idempotency