new·Earn with mozg — 20% of every monthSend somebody here and take a fifth of every plan payment they make, for as long as they keep paying — not a bounty on the first invoice. Your handle is the link, the window is thirty days, and the commission lands on your balance the second they pay. Free to join: if you have signed in, you already have the link. mozg.sh/earnall news →
mozg.beta
Sign in

Temporal · Concepts · all subjects

event-history & replay

6 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Command definition

A Command is a requested action issued by a Worker to the Temporal Service after a Workflow Task Execution completes. The action that the Temporal Service takes is recorded in the Workflow Execution's Event History as an Event. The Workflow Execution can await on some of the Events that come as a result from some of the Commands.

State Transition definition

A State Transition is a unit of progress made by a Workflow Execution. Each State Transition is recorded in a persistence store.

State Transitions example for Activity Heartbeats

Some operations, such as Activity Heartbeats, require only one or two State Transitions each. With an Activity Heartbeat, there are two: the Activity Heartbeat and a Timer.

State Transitions example for simple workflow

A simple Workflow with two sequential Activity Tasks (and no retries) produces 11 State Transitions: two for Workflow start, four for each Activity, and one for Workflow completion.

How Commands relate to Event History and replay

Workflow APIs generate Commands which tell the Temporal Service which Events to create and add to the Workflow Execution's Event History. When the Workflow code replays, the Commands that are emitted are compared with the existing Event History. If a corresponding Event already exists within the Event History that matches that command, then the Execution progresses. If a generated Command doesn't match what it needs to in the existing Event History, then the Workflow Execution returns a non-deterministic error.

Timers are persisted across Worker and Service downtime

Timers in Temporal are persisted, meaning that even if your Worker or Temporal Service is down when the time period completes, as soon as your Worker and Temporal Service become available, the call that is awaiting the Timer in your Workflow code will resolve, causing execution to proceed.

Give your agent this brain