Engineering journal
Retrying AI Workers Without Duplicating Actions
Omniweft keeps mutation authority in the parent and policy host. A crashed or superseded worker cannot revive a proposal, and explicit retry preserves the exact request when delivery is uncertain.
Source: https://louijiecompo.com/writing/retrying-ai-workers-without-duplicating-actions/
About 4 min read
| Phase | Status | World revision |
|---|---|---|
| timeout | timed_out | 0 |
| cancelled | cancelled | 0 |
| crashed | crashed | 0 |
| superseded | superseded | 0 |
| replacement | committed | 1 |
| restarted | committed | 2 |
Recorded statuses from the public archive. Prevented proposals leave the world at revision zero.
A worker can crash before proposing an edit. A response can also disappear after the edit has already committed. Those failures look similar to a caller waiting for an answer, but require different recovery decisions. Starting a replacement worker does not tell the caller whether the world changed.
Omniweft's merged PR-015 slice, delivered in GitHub PR #21, puts that distinction in an explicit lifecycle. The worker proposes; the parent retains mutation authority. The subsequent PR #22 corrects one deadline boundary without changing that authority model. This article reviews the public contracts and retained CPU evidence, not a new engine execution or a model benchmark.
Keep authority out of the worker
The worker lifecycle contract (opens in a new tab) launches a fixed bundled proposal worker. Typed goals include a captured world revision, request identity and generation. The worker receives no session token, epoch or prepared transaction. The parent accepts or rejects proposals and submits through the existing policy host.
The supervisor permits one active request and retains at most eight statuses without eviction. At most two bounded children can exist while old output drains, and IPC frames are capped at 16 KiB. These are specific protocol and lifecycle bounds, not a claim of globally bounded process memory or OS sandboxing.
Before submission, timeout, cancellation, crash and supersession prevent mutation. Late output cannot change a terminal status or become a fresh proposal. The retained fixture above shows those prevented phases at world revision zero. The same fixture later creates a cube at x=3 and moves the same identity to x=4, advancing world revisions to one and two.
Submission changes what cancellation means
Once explicit submission begins, cancellation is too late. The parent cannot safely interpret “the caller stopped waiting” as “the edit did not happen.” Replacement authoring stays blocked until the outcome is known or explicitly reconciled.
For an uncertain submission, the parent keeps the exact prepared transaction. Restarting a worker does not discard it. This preserves the original request identity, expected revision, budget and operations instead of silently creating a second request that could repeat the action.
The opt-in retry profile (opens in a new tab) checks live authentication and policy before replaying a retained receipt. Canonically identical requests can recover that receipt; a different payload under the same key is rejected. JSON whitespace is not request identity. Legacy SDK profiles keep their existing resynchronization behavior.
A receipt is evidence of the original action
The retained transport proof (opens in a new tab) loses an actual response after native commit. Explicit same-key retry through a provider restart recovers the original receipt without creating another entity or incrementing the world revision a second time.
That proof is stronger than checking a state-machine unit test alone: it exercises a real child process and native transport. Its scope is still narrow. Scripted fixture data is not evidence of language-model judgment, arbitrary agent safety, physical GPU behavior or physics.
Expiry requires a different decision
The host keeps four receipts per principal with an absolute 2,000 ms retention window. Replaying a receipt does not extend that window. After expiry, the system requires explicit reconciliation; it does not allocate a replacement key and assume replay is harmless.
The supervisor also distinguishes a proposal deadline from receipt retention. A deadline that expires while the parent prepares an unsent key permits reconciliation only, not a first submission disguised as retry. Observing the world is useful, but observation alone does not clear a pending prepared request.
These boundaries prevent a convenient retry API from silently changing the meaning of an action. If a receipt is no longer available, the next step is to establish the outcome, then deliberately decide whether a new action is appropriate.
Restart must preserve an already expired status
PR #22 fixes a subtle public-call ordering case. If a ready proposal has expired and restart is the next call, expiry now runs before supersession. At or after the deadline, the status remains timed_out / DEADLINE_EXPIRED. Just before the deadline, restart can still supersede it.
The retained regression uses real cleaned, ready child processes and a controlled parent clock for the exact deadline boundaries. Prepared, submitting and uncertain requests retain their original authority and recovery rules. There is no background expiry notification service: a public method observes the transition.
Draw the durability boundary precisely
Worker recovery assumes the parent supervisor and native policy host survive. Local statuses are not persistent, and the retry host is volatile. Omniweft also has a separate bounded native persistence contract (opens in a new tab), but that does not make this supervisor or policy host durable across a host crash.
The design lesson is to bind recovery to the original authority and request, and to expose uncertainty when that evidence is insufficient. The diagram describes that contract; the downloadable records preserve the observed fixture. Continue with the Omniweft case study or its current engineering note.