Inconsistent test failures due to a race condition

[sarahec]

While building for nixpkgs, two tests are failing frequently -- but not consistently -- on aarch64-darwin (MacOS):

test_fritzmonitor.py::test_terminate_thread_on_failed_reconnection[data7-5-5-False] - assert True is False test_fritzmonitor.py::test_restart_failed_monitor - assert True is False

The second failure appears to be tied to the first one (they only appear together).

It looks like a classic race condition where time.sleep(0.01) may not be long enough fr the socket to disconnect under some conditions.

=========================== short test summary info ============================
FAILED fritzconnection/tests/test_fritzmonitor.py::test_terminate_thread_on_failed_reconnection[data7-5-5-False] - assert True is False
FAILED fritzconnection/tests/test_fritzmonitor.py::test_restart_failed_monitor - assert True is False
================== 2 failed, 400 passed, 10 skipped in 1.96s ===================
error: builder for '/nix/store/kviik1lr4hcw6ns78v8i1lqp87k44zcs-python3.12-fritzconnection-1.15.0.drv' failed with exit code 1;
       last 25 log lines:
       >         started again. Starting the same instance twice does (and should)
       >         not work. See test_start_twice(). But after a failed reconnect (a
       >         lost connection) the same instance without calling stop()
       >         """
       >         socket = MockReconnectFailSocket(
       >             mock_data=["first\n", "", "second\n"], timeouts=16
       >         )  # just some timeouts
       >         fm = FritzMonitor()
       >         fm.start(
       >             sock=socket, reconnect_delay=0.001, reconnect_tries=5
       >         )  # set default explicit for clarity
       >         # give socket some time to lose connection:
       >         time.sleep(0.01)
       > >       assert fm.is_alive is False
       > E       assert True is False
       > E        +  where True = <fritzconnection.core.fritzmonitor.FritzMonitor object at 0x1058e5b50>.is_alive
       >
       > fm         = <fritzconnection.core.fritzmonitor.FritzMonitor object at 0x1058e5b50>
       > socket     = <fritzconnection.tests.test_fritzmonitor.MockReconnectFailSocket object at 0x1058e6bd0>
       >
       > /nix/var/nix/builds/nix-build-python3.12-fritzconnection-1.15.0.drv-0/b/source/fritzconnection/tests/test_fritzmonitor.py:385: AssertionError
       > =========================== short test summary info ============================
       > FAILED fritzconnection/tests/test_fritzmonitor.py::test_terminate_thread_on_failed_reconnection[data7-5-5-False] - assert True is False
       > FAILED fritzconnection/tests/test_fritzmonitor.py::test_restart_failed_monitor - assert True is False
       > ================== 2 failed, 400 passed, 10 skipped in 1.96s ===================
       For full logs, run 'nix log /nix/store/kviik1lr4hcw6ns78v8i1lqp87k44zcs-python3.12-fritzconnection-1.15.0.drv'.

[kbr]

Thanks for the report. On macOS (<= 15) I have never run into this. Are you able to check whether increasing the sleep time may solve the issue for you? In this case we can adapt the test, because the sleep time is just an arbitrary value.

[sarahec]

I expect that increasing the sleep time would work. The first test fails intermittently and (as far as I know) with that one data set. It also leaves the system in an inconsistent state so that the next test fails.This happens a lot for Python devs: timings that work on your machine fail in our very busy CI system. We normally disable the test and file an upstream bug then reinstate the test on the next update.On Nov 4, 2025, at 08:54, Klaus Bremer @.***> wrote:kbr left a comment (kbr/fritzconnection#251) Thanks for the report. On macOS (<= 15) I have never run into this. Are you able to check whether increasing the sleep time may solve the issue for you? In this case we can adapt the test, because the sleep time is just an arbitrary value.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>