tests/test_aio.py::test_the_loop_runs_while_a_stream_waits_for_a_batch sleeps 50 ms while a task ticks every 1 ms and asks for more than ten ticks. On windows 3.14 it gets nine.
assert ticks > 10
E assert 9 > 10
The thing under test is right and the counter is not. asyncio.sleep(0.001) on Windows does not sleep a millisecond: the proactor loop's resolution is the system timer, which is about 15.6 ms unless something has asked the OS for better, so fifty milliseconds of wall clock buys three or four turns of a 1 ms sleep and the nine ticks it did get were mostly the loop being generous. The same code on Linux and macOS gets hundreds and the test looks fine there.
What the test means is that the loop is not blocked while a batch is in flight, and the number ten is standing in for "more than a couple". Two ways to say that without counting a platform's timer. Count turns rather than sleeps: have the ticker await asyncio.sleep(0) and assert it ran many times, which measures the loop yielding and not the clock granularity. Or keep the sleep and scale the threshold off a measured baseline, ticking for the same 50 ms with no stream open and asserting the stream costs no more than a fraction of that.
The first is what the test is actually about. A loop that never yields gets zero either way, and that is the failure worth catching.
It fails on windows on main as well as on branches, so like #33 it is a gate nobody can read.
tests/test_aio.py::test_the_loop_runs_while_a_stream_waits_for_a_batchsleeps 50 ms while a task ticks every 1 ms and asks for more than ten ticks. On windows 3.14 it gets nine.The thing under test is right and the counter is not.
asyncio.sleep(0.001)on Windows does not sleep a millisecond: the proactor loop's resolution is the system timer, which is about 15.6 ms unless something has asked the OS for better, so fifty milliseconds of wall clock buys three or four turns of a 1 ms sleep and the nine ticks it did get were mostly the loop being generous. The same code on Linux and macOS gets hundreds and the test looks fine there.What the test means is that the loop is not blocked while a batch is in flight, and the number ten is standing in for "more than a couple". Two ways to say that without counting a platform's timer. Count turns rather than sleeps: have the ticker
await asyncio.sleep(0)and assert it ran many times, which measures the loop yielding and not the clock granularity. Or keep the sleep and scale the threshold off a measured baseline, ticking for the same 50 ms with no stream open and asserting the stream costs no more than a fraction of that.The first is what the test is actually about. A loop that never yields gets zero either way, and that is the failure worth catching.
It fails on windows on main as well as on branches, so like #33 it is a gate nobody can read.