WDK Event-Sourced Replay
If you remember one thing about durable execution, remember this: workflow code runs many times and the event log decides what's real. That single fact explains every WDK rule — why steps must be idempotent, why you can't read `Date.now()` directly in a workflow, why parameters are passed by value, why mutating an object inside a step doesn't propagate, and why bundlers occasionally bite you. Internalize the replay model and the rest of WDK (and Temporal, and Cloudflare Workflows) becomes obvious.
What It Defines
The mechanism that makes Workflow DevKit durable. Every `"use step"` call writes its inputs and result to an append-only event log; the workflow function itself is replayed from the start whenever it needs to resume (after a sleep, a crash, a hook, a deployment). On replay, each completed step short-circuits and returns its logged result without re-executing. This requires the workflow body to be deterministic — it runs in a sandbox where `Math.random()`, `Date.now()`, and the `Date` constructor are intercepted to return their original recorded values, and most npm imports are restricted (steps are where arbitrary code lives). Same event-sourcing pattern Temporal popularized and Cloudflare Workflows / DBOS / Restate now use.
Canonical (Normative)
Convenient (Practical)
Related References
Frontend cloud platform and the steward of the open-source Workflow DevKit (Apache-2.0). Vercel publishes the WDK spec and reference implementation ("use workflow" / "use step" directives, durable timers, hooks, streaming) and runs the integrated workflow runtime on its platform. WDK can also be self-hosted on Docker, AWS, or DigitalOcean. Vercel also publishes the AI SDK and the Vercel Functions runtime spec.
Related Specs
WDK is the durable-execution model arriving inside the JavaScript ecosystem proper: instead of writing a state machine, you write `async` code with two extra string directives and you get crash-safe, resumable, retry-aware, observable workflows. If you're building AI agents, multi-step background jobs, human-in-the-loop flows, or anything that previously needed BullMQ + a state machine + careful idempotency, WDK collapses that into a single mental model. Even if you don't pick WDK specifically, the directives + replay model are the durable-execution pattern Temporal pioneered and Cloudflare/Restate/DBOS now ship — knowing one teaches you the rest.
The deeper pattern under every durable-execution runtime. If you understand event sourcing, you understand why a WDK workflow function runs over and over and gets the same answer, why steps must be deterministic on the workflow side, and why activities/steps can be retried freely. Also useful in its own right — for ledgers, audit logs, CQRS read models, and any system where "how did we get to this state?" is a real question.
Durable execution removes the "did the request actually go through?" anxiety, but only if your steps are idempotent. The single most common WDK / Temporal / Step Functions bug is a non-idempotent step that sends two emails on retry. Treat steps like HTTP PUTs: design them to be safely repeatable, key your side-effecting external calls with a deterministic id, and the rest of the model takes care of itself.
Most "my workflow exploded after a deploy" reports come down to something non-serializable hiding in a step argument or return value. Treat the boundary like an API: pass plain data, return plain data, do all I/O and mutation inside steps, and never assume an object reference survives. Same discipline applies to Temporal activities and Step Functions tasks — it's a property of event-sourced replay, not a WDK quirk.
Temporal is the prior art every durable-execution framework is measured against. If you're picking a workflow runtime, evaluating WDK, or reading a paper on durable execution, the Temporal model — workflows + activities + signals + timers + event history — is the vocabulary. Even if you choose WDK or Step Functions for a specific stack, understanding Temporal makes their tradeoffs legible (sandbox restrictions vs full Node, hosted runtime vs self-host, JSON DSL vs code).