RoutingService never exits after its five socket-error limit #267

Describe the bug

RoutingService.run has an outer while socket_error_count < 5 loop, but receives packets inside an unconditional inner while True. Socket errors increment the counter and sleep without leaving the inner loop, so the five-error limit is never rechecked.

A persistently failing receive therefore continues retrying and logging indefinitely. This can also occur when a subsequent read sees a socket that has been closed. The report concerns the loop's existing retry limit, not the separate multi-CPU port-assignment issue.

To reproduce

On dev at 9fb1174cc118bf0a31453401adf052e448617e84, run the routing loop with a socket whose recvfrom raises OSError five times. Replace sleep with a no-op for the test, and make a sixth receive raise an assertion instead of hanging the test process. The assertion is reached on the current source.

The same effect reproduces after a real datagram is received over an ephemeral loopback UDP port, followed by five read timeouts.

Expected behavior

Exit run after the fifth cumulative socket error, as the existing outer condition specifies. Keep the one-second delay, successful forwarding, short-packet filtering, spacecraft discovery and non-socket exception propagation unchanged.

Tests and system

Seven standard-library unittest methods cover persistent/interspersed errors, ignored short packets, host-to-topic routing, bind failures, non-socket failures and real loopback UDP reception. Five cases fail against the unchanged code; the two exception-propagation controls pass. Removing the redundant inner loop makes all seven pass.

macOS, Python 3.12.11, PyQt5 5.15.11 and pyzmq 27.2.0. Tests call run synchronously, mock the publisher and socket-error delay, and use no flight hardware or deployed cFS system.

Reporter

Sylvester Kaczmarek (sylvesterkaczmarek), Personal.