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:
+6
-1
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user