// HACKER NEWS — CYBERSECURITY
Durable execution without history replay
Most durable execution systems recover by replaying retained execution history. After a worker fails, a fresh worker loads the history and re-executes the program until it reconstructs the current position.
This is a useful model. It provides durable progress while allowing workers to remain ephemeral. But it also makes accumulated history part of the recovery path.
That tradeoff becomes more noticeable for programs that operate for hours or days, call many tools, wait for external events, create child executions, and change direction dynamically. Long-running agents increasingly have this shape.
I’ve built and evaluated a different recovery primitive: checkpointing the program continuation instead of reconstructing it from history.
I call the approach Transparent Continuation Checkpointing, or TCC.
At durable boundaries, the compiler and runtime capture the live continuation: the control state required for the program to continue from its current position. When execution resumes after a failure, the runtime loads the committed continuation and restores the program directly.
Load retained history → re-execute the prefix → reconstruct the current position
Load committed continuation → restore live execution state → resume
External effects remain explicit durable operations. Completed durable work is not repeated after recovery, and unsupported language constructs fail during compilation rather than producing ambiguous runtime behaviour.
The current prototype supports durable effects, external waits and events, child executions, cancellation, structured concurrency, and crash recovery.