Events

Every significant action in a workflow's lifetime produces an event: the workflow started, an activity was scheduled, an activity completed, a signal was received, the workflow finished. These events are recorded in order, forming an append-only log called the execution history.

The execution history is what makes durable execution possible. It is the source of truth for a workflow's state. When a worker needs to resume a workflow — after a crash, a restart, or a task reassignment — it replays the execution history from the beginning.

During replay, workflow code runs again from the top. But completed activities are not re-executed: their results are read back from the history. And because workflow code is deterministic, the same sequence of operations is produced every time, and the workflow arrives back at exactly the point where it was interrupted. This is the mechanism that makes workflows resilient to failures without any recovery code on your part.

Determinism is what makes replay reliable: if workflow code produces a different sequence of operations on replay — because it called datetime.now() or random() and got different values — the replay diverges from the recorded history and the workflow fails. This is why non-deterministic operations must happen in activities, not in workflow code.

Each execution history is bounded: 51,200 events or 50MB, whichever comes first. For workflows that run for a very long time or process very large volumes of work, the platform provides a mechanism called continue-as-new, which allows a workflow to carry its essential state forward into a fresh history without interrupting its execution.