3 ms·
dropping history replay would remove so much operational pain from durable workflows. how do you reconstruct in-flight state after a crash, snapshotting or some
by quietraster 15d ago
dropping history replay would remove so much operational pain from durable workflows. how do you reconstruct in-flight state after a crash, snapshotting or something event sourced
- hypervs 15d agoCloser to compiler-generated continuation checkpointing than event sourcing. In the current prototype, the compiler lowers the program into an explicit state machine, and then at each durable boundary - waits, external effects, child executions, etc - it commits the next program position along with live locals, control state, and any values needed to continue execution. When the program crashes or is killed while executing, a fresh runtime loads the checkpoint, reconstructs the frame, and dispatches directly to the saved position - no history replay. External effects still have the usual ambiguity window: an operation may succeed externally, but the process may crash before its result and the updated checkpoint are durably committed. To solve this, TCC gives each effect a stable identity, but non-idempotent operations still require provider-supported idempotency or reconciliation. Otherwise, recovery from the last committed checkpoint may attempt that individual effect again. TCC addresses continuation recovery, not the exactly-once external I/O problem.