Clicking on this red x on our front page here we see that the Linux build passed, the MacOS failed, the Windows build was not attempted.
Copilot suggests this about the failure:
The failure occurred in test/test_ca.py at test_addr_claim_fixed_reduced_time (line 78):
assert len(feeder.can_messages) == 0
But len(feeder.can_messages) was 1, not 0. This means a message remained unprocessed.
Problem:
In test_addr_claim_fixed_reduced_time, the following code controls the timing:
71| new_ca.start(0.25)
75| time.sleep(0.3)
This only waits 0.3 seconds after starting the ControllerApplication, which may not be enough on all systems for asynchronous message processing, especially with thread scheduling variance.
Solution:
Increase the sleep duration in the test to ensure all messages have been processed:
Replace:
time.sleep(0.3)
With:
time.sleep(0.6)
This will give the background thread enough time to process and clear feeder.can_messages before the assertion. Here’s the adjusted code block from test_addr_claim_fixed_reduced_time:
# wait until all messages are processed asynchronously
# rounded up to account for scheduling delays
time.sleep(0.6)
Alternatively, use a polling loop similar to the one in address_claim to actively check until feeder.can_messages is empty:
while len(feeder.can_messages) > 0:
time.sleep(0.1)
time.sleep(0.1)
Either of these will make the test more robust and prevent spurious failures caused by insufficient wait time.
Clicking on this red
xon our front page here we see that the Linux build passed, the MacOS failed, the Windows build was not attempted.Copilot suggests this about the failure: