OpenClaw merged a Gateway reliability fix tonight in PR #123869, focused on paired node workers under concurrent load. The bug was subtle but operationally important: an agent turn could finish, visibly apply its assistant result, and then incorrectly fail workspace reconciliation because the node was temporarily at launch capacity.
That kind of failure is dangerous because it looks like a failed turn after side effects have already happened. Operators may retry, callers may make wrong assumptions, and automation can lose confidence in a result that was actually delivered.
What Changed
The fix separates two ideas that had become entangled during node-host reconciliation:
- the immutable build advertised by the authenticated node connection;
- the node's transient eligibility to launch more work at that moment.
When a node is full, it should not be treated as disconnected or as advertising the wrong build. The merged change keeps post-turn workspace work fenced to the correct build while avoiding the false "expected build" failure caused by launch saturation.
The PR also changes recovery behavior. Reconcile failures now request targeted recovery immediately instead of waiting for the periodic sweep, and unchanged accepted manifests are not copied back to a node that already has them.
More Honest Wait Results
The same patch fixes another load-related edge case: queued chat turns could report a terminal successful wait before the queued work had actually settled.
After this change, agent.wait reports pending while the chat turn still exists in the queued-turn owner. That is a small API behavior detail with a big workflow impact. A successful terminal wait should correspond to an eventual visible outcome, not simply to a turn that has been accepted into a queue.
Who Benefits
This is most relevant for operators running shared paired nodes, large sessions, or several concurrent turns against the same node host. Those are exactly the environments where launch capacity is likely to be reached temporarily.
The practical result is calmer automation:
- visible assistant results are less likely to be followed by false workspace errors;
- callers see queue truth while work is still queued;
- terminal success has a stronger relationship to visible completion;
- redundant transfer work is reduced for unchanged manifests.
The PR states that TLS behavior is unchanged.
Verification
The evidence attached to PR #123869 includes a pre-fix regression replay, 171 focused node registry, tunnel, placement recovery, and launcher tests, plus follow-up coverage across the affected registry, tunnel, wait, and chat suites.
The strongest proof is the sustained real node-host rig: three repetitions produced 108 visible markers, 108 successful waits, zero TLS or listener failures, and all placements active. A large-sync rig added 18 successful launches and visible markers, with queued intervals reporting pending/queue.
The Bottom Line
PR #123869 tightens OpenClaw's node-host behavior where reliability matters most: after the assistant has already done visible work. Under load, the system now distinguishes "the node is busy" from "the node is wrong," and waits no longer turn green before queued work has truly settled.