Skip to content

Guide overview ​

Pulse Durable adds checkpoint storage and recovery to Pulse graphs. It suits workflows with explicit node boundaries that need to reuse completed steps after an interruption, such as document processing stages, batch tasks, or long computations.

Pulse owns graph definitions, dependency scheduling, Aspects, and observation of the current execution. Durable saves complete node results and attempt state, then restores valid results into a new execution. The host still starts processes, supplies inputs, selects run identities, and handles external effects.

Before you start ​

You need Go 1.26 or later and access to module downloads. Current tutorials target Durable v0.1.0 and Pulse v0.5.0, not a claim of publication: check GitHub Releases; installation commands are unavailable before their tags are published. The minimal example uses MemoryStore, and the recovery tutorial uses filestore; complete SQLite and PostgreSQL tutorials are also available.

If graphs, typed Keys, and declared outlets are new to you, start with the Pulse quick start. The Durable tutorials provide their own complete programs and dependency versions.

Complete your first recovery ​

  1. Installation: create a module, pin the dependency, and check Go and Pulse versions.
  2. Quick start: run one node and read a declared outlet with value 42 and state ready.
  3. Recovery after process exit: exit the process inside a downstream node, then load the checkpoint in a new process and finish the run.

In the third step, the upstream body runs once and the downstream body runs once before exit and once after restart. This is Durable's central rule: reuse confirmed nodes and restart unconfirmed nodes from the beginning of their functions.

Add recovery to your application ​

NeedGuide
Compose stages into a child graph and retain Retry progressSubgraphs and retries
Persist structs, named types, or special encodingsValue codecs
Choose a directory, investigate lock contention, or add a backendStorage
Use local SQLite and recover in another processSQLite tutorial
Use PostgreSQL with DSN, permissions, and connectionsPostgreSQL tutorial

If a business function calls an external system before its checkpoint is confirmed, recovery may call that function again. Establish idempotency keys, transaction boundaries, or an outbox when integrating your application.

Check rules and handle errors ​

The guides explain tasks. The reference defines API and persistent record constraints:

  • Execution contract: RunID, Version, recovery compatibility, cancellation, and recovery events.
  • Data model: scopes, attempts, value states, codecs, and the Store CAS protocol.
  • Error handling: different responses to argument errors, contention, conflicts, and CheckpointError.

When a call fails, identify its error category first. A storage save may report an error after committing; stop this execution and reload the record when recovering. Repeated Resume calls do not increase an exhausted Retry budget.

Current scope ​

Supports ordinary values, managed streams, explicit message state, and static child graphs. See the Data model for reliable stream boundaries. filestore supports recovery after local process exit; MemoryStore retains records only while the same process is alive. Durable does not provide durable waits, distributed run management, deterministic replay, or exactly-once external effects.

Next: Installation.

Target v0.1.0 · Go 1.26+ · Pulse v0.5.0 · Release status: GitHub Releases · MIT