Resume Is Not Retry

Apache Maka’s recovery design addresses a dangerous ambiguity: what may the system do after a process disappears in the middle of a tool operation? This chapter diagnoses that ambiguity from the durable facts around a crash, then separates three different actions—repairing the old Run, reconciling an outside effect, and continuing from a safe boundary. The practical judgment is whether a “resume” operation creates a new, evidence-bound execution or merely repeats an unknown mutation under a friendlier name.

Consider a simple request: change a port in config.json from 3000 to 4000. The model calls an editing tool. The process crashes before the tool result appears. After restart, the Runtime cannot responsibly assume that the edit did or did not happen. The tool may never have started. It may have started and failed before writing. It may have written the new value and then lost the result while recording it. Or the file may have been changed again by a person or another process.

Those possibilities have different consequences. Repeating the edit could be harmless in one case and a duplicate side effect in another. Declaring success could make the model skip necessary work. Calling the event a generic failure hides the fact that the outside workspace may already have changed. Recovery begins by refusing to make the missing result mean more than the evidence supports.

The same missing result has several causes

The earlier side-effect protocol gives the Runtime two important landmarks. T1 records that preflight passed and dispatch may have begun. T2 records the tool response and outcome before the next model step uses them. The tool implementation runs between those two short durable commits.

A crash before T1 is different from a crash after T1. If the active protocol proves that no dispatch boundary was crossed, the Runtime may be able to classify the operation as definitely not dispatched. But that conclusion depends on the protocol and the committed event prefix. An old or incomplete ledger cannot obtain certainty merely from the absence of a row.

After T1, the uncertainty is wider. The edit may have changed the file, but T2 may not have recorded the result. A missing T2 therefore means “the operation is unresolved,” not “the tool failed” and not “the tool never ran.” If T2 exists and matches the call, the result is completed history and must not be executed again just because a client or process missed a notification.

The difference is easy to state but difficult to preserve in a hurried recovery path. A retry button usually assumes that the previous attempt did not count. Maka’s model asks a different question: what durable facts exist, and what external evidence can settle the gap? That change in wording prevents a user interface from converting uncertainty into an instruction to repeat.

Repair, reconcile, and resume answer different questions

Maka gives three names to three different jobs.

Repair concerns the old Run. If a process died while the Run was still marked active, startup reads its durable RuntimeEvents and operational records and commits a terminal fact that closes the interrupted execution. Repair makes the old Run inspectable and prevents it from remaining “running” forever. Repair does not prove that an unfinished tool had no side effect.

Reconcile concerns the outside operation. If T1 exists but T2 does not, a tool-specific observer may inspect the file, service, or other external system and gather evidence about whether the effect completed. A future file reconciler, for example, could compare a durable before-state and expected-after-state. If the evidence matches the expected result, the Runtime could finalize without writing the file again. If the file matches the prior state, has diverged, or cannot be read safely, the correct result is to park rather than guess.

Resume, or safe-boundary continuation, concerns a new execution.