« Phase 08 README · Warmup · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes
Phase 08 — Hitchhiker's Guide
30-second mental model
Durable execution = event sourcing + deterministic replay. Every side effect is a recorded
activity; to recover from a crash, re-run the workflow from the top, replaying recorded
activities (not re-executing them) until you reach live work. The workflow must be deterministic
(no wall-clock/random/I/O — those go in activities or ctx.now()). Memoized activities = exactly-
once side effects across crashes. Signals resume a suspended workflow (durable human-in-the-
loop). This is Temporal.
The facts to tattoo on your arm
| Fact | Why |
|---|---|
| workflow = deterministic orchestration | it's replayed; must reproduce the same commands |
| activity = side-effecting, recorded, retried | where I/O and non-determinism live |
| replay memoizes activities | no double charges/emails after a crash |
ctx.now() not time.time() | wall-clock in workflow code = #1 durability bug |
| retries safe only if idempotent | otherwise retries multiply side effects |
| signal → suspend/resume | wait for a human for days, holding no resources |
| saga = step + compensation | undo completed steps on late failure |
Framework one-liners
- Temporal — the canonical durable-execution engine; workflows + activities + workers + a determinism checker; a whole JD in this track.
- Azure Durable Functions / AWS Step Functions — managed durable orchestration.
- DBOS / Vercel Workflow (WDK) — modern lightweight takes.
- Temporal AI SDK — plugs durable execution into Pydantic AI, OpenAI Agents SDK, ADK, Vercel AI SDK (exactly Temporal's "AI Foundations" JD).
War stories
- The clock bug. A workflow set a deadline with
datetime.now(); it worked for weeks, then a replay computed a past deadline and the workflow "expired" instantly. Determinism checker would have caught it;ctx.now()fixes it. - The double refund. A non-durable job crashed after refunding and re-ran from scratch, refunding again. Durable memoization makes it exactly-once.
- The thread that waited three days. A naive "wait for approval" held a worker thread for the whole approval SLA. A signal-based suspend holds nothing.
Vocabulary
Durable execution · workflow / activity · event sourcing · history · deterministic replay · determinism checker · memoization · idempotency key · retry / backoff · signal · suspend/resume · saga / compensation.
Beginner mistakes
- Reading the wall clock / random / doing I/O in workflow code.
- Retrying a non-idempotent activity (double side effects).
- Storing "current state" instead of the event log.
- Holding a thread/connection while "waiting" instead of using a signal.
- Putting orchestration logic inside an activity (it won't replay right).
- Thinking durability = checkpoint-all-variables (it's replay).