OpenClaw Main Stops Retrying Node Commands When Execution Is Uncertain
Three merged fixes add deadlines and dispatch provenance to node-hosted exec, then report ambiguous outcomes instead of risking duplicate side effects.
OpenClaw has merged a three-part correction for commands executed with exec host=node: when a timeout, disconnect or malformed reply leaves the Gateway unable to prove whether system.run executed, the result should now be reported as ambiguous rather than denied, undispatched or safely retryable.
That distinction matters whenever a command can create, send, mutate or delete something. Retrying after an uncertain outcome can duplicate the side effect even if the first call only appeared to fail.
The changes are on main; inclusion in an installed package must be confirmed separately.
What was unsafe
A distributed command has at least two relevant facts:
- whether the Gateway dispatched it; and
- whether the caller received an authoritative terminal result.
Those facts can diverge. A node may accept and run a command just before the transport disconnects. The caller sees no valid result, but “no result” is not the same as “nothing ran.”
PR #117276 says timeout, disconnect and malformed post-invoke failures could be projected as denial or non-dispatch even when execution could not be ruled out. Automatic fallback or retry logic could then run the command again.
PRs #117139 and #116591 supply the lower layers: preserve dispatch provenance through the Gateway and arm the invocation deadline from the host=node exec path. Without both, a higher-level error cannot reliably distinguish pre-dispatch rejection from post-dispatch uncertainty.
The operator decision
Treat an ambiguous result as an incident requiring reconciliation, not as permission to retry.
| Outcome | Safe default |
|---|---|
| Authoritative denial before dispatch | Correct policy or approval, then submit deliberately |
| Authoritative command failure | Inspect the reported failure before deciding whether repetition is safe |
| Success with a terminal result | Record the result and do not replay |
| Ambiguous after possible dispatch | Check node and target-system evidence; retry only with an idempotency guarantee |
The last row is the one this change makes visible.
Acceptance test
After moving to a revision containing all three merged fixes:
- use a disposable node and a harmless command that writes a unique marker;
- record the invocation or idempotency identity;
- force a disconnect after dispatch but before the terminal reply;
- confirm OpenClaw reports uncertainty rather than denial or a clean non-dispatch;
- prove the framework does not automatically issue a second invocation;
- reconcile the marker on the node; and
- repeat with a failure before dispatch to prove genuinely safe resubmission is still distinguishable.
Do not test with package publication, account changes, external messages or destructive filesystem operations. The point is to prove classification without creating a real duplicate.
Design commands to survive uncertain completion
The merged behavior reduces risk but cannot make a non-idempotent command magically safe. Operators should still:
- attach a stable operation key to important remote mutations;
- make target systems reject or return the prior result for duplicate keys;
- log dispatch and completion separately;
- set deadlines long enough for the real command budget;
- avoid fallback paths that reinterpret transport failure as policy denial; and
- provide a reconciliation query that does not repeat the mutation.
Interpretation: a useful automation result has three states, not two: succeeded, failed authoritatively, or unknown after possible execution. Systems that collapse the third into failure eventually duplicate work.
Evidence and limits
The official merged-PR and commit records establish the reported fault, the deadline wiring, dispatch-provenance preservation and the new ambiguous-outcome behavior. Direct GitHub page extraction returned HTTP 403 during this run, so OpenClaw Academy relied on the repository collector’s official GitHub records and did not independently execute a command against an OpenClaw node.
Bottom line
If you run side-effecting commands on nodes, adopt a containing build through staging and alert on ambiguous outcomes as their own class. Never let “the reply disappeared” become “run it again” without first proving what happened at the node.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF