JIXU DOCUMENTATION
Recovery, Replay, and Fork
Three different operations for continuity, inspection, and branching.
These operations all begin with durable Events, but they solve different problems.
| Operation | Purpose | Performs live Effects? | Mutates the parent? |
|---|---|---|---|
| Recovery | Resume eligible pending work after a process boundary | Only when the durable boundary permits it | Continues the same Thread |
| Replay | Rebuild State from history | Never | No |
| Fork | Continue from an earlier Event in a child Thread | The child may perform later Effects | No |
Recovery
const thread = await harness.openThread(threadId);
const state = await thread.wait();Opening a Thread reconstructs State, classifies pending Effects, and resumes only work whose semantics allow dispatch. A stable Effect identity is reused when an idempotent retry is valid.
If an external outcome is unknown and cannot be retried safely, the Thread enters waiting. Jixu keeps the uncertainty visible instead of guessing success or failure.
Replay
const state = await thread.replay();Replay reads Events and runs the pure projection path. It dispatches no model, Tool, compaction, network, or filesystem Driver.
Use Replay to audit history, verify a Store, rebuild a disposable Checkpoint, or test reducer compatibility.
Fork
const child = await thread.fork({
at: eventId,
input: "Try the conservative implementation from this point.",
});Fork creates a new Thread with explicit parent lineage and the exact projected State at the chosen Event. The parent remains immutable. Later child Events receive child identities rather than reusing parent request or Effect identities.
The decision rule
- The process stopped and valid work should continue: recover.
- You need to inspect the same history without side effects: Replay.
- You want an alternative continuation without rewriting the parent: Fork.