fix requests queued while the arm is down never being answered

_run_control never drained the job queue while the arm had not been reached, so
every request that arrived during an outage waited for a connection that might
never come. That breaks the one-response-per-request rule the node states as
absolute, and it was circular: requests are queued before the arm is reached
because recover is what a caller sends then, yet recover is served by the
control thread and so was the one service that could never run while down.

Serve the queue during the wait between connection attempts. Non-motion services
are tried on the arm, which is what lets recover and clear reach a controller
that answers while refusing to serve. A motion is refused rather than held: the
arm is somewhere unknown and nobody is watching, so a held motion would fire
unattended the moment the link came back.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-09-15 12:32:31 -05:00
co-authored by Claude Opus 5
parent 608e22078e
commit 4427da9c34
4 changed files with 104 additions and 5 deletions
+6 -1
View File
@@ -30,11 +30,16 @@ class FakeArm:
self.recover_error = None
self.block = None
self.stopped = False
self.connected = True
# --- reads ---
def is_connected(self):
return True
return self.connected
def connect(self):
self.calls.append("connect")
return self.connected
def is_ready(self):
return self.ready