In Nixpkgs CI, test_run_coro_with_timeout is sporadically failing and then getting better without any apparent cause (for example, see https://hydra.nixos.org/job/nixpkgs/staging-next/python314Packages.zeroconf.x86_64-linux for the CI run history). I also couldn't immediately reproduce the failure locally.
The error output is this:
=================================== FAILURES ===================================
__________________________ test_run_coro_with_timeout __________________________
@pytest.mark.asyncio
async def test_run_coro_with_timeout() -> None:
"""Test running a coroutine with a timeout raises EventLoopBlocked."""
loop = asyncio.get_event_loop()
task: asyncio.Task | None = None
async def _saved_sleep_task():
nonlocal task
task = asyncio.create_task(asyncio.sleep(0.2))
assert task is not None
await task
def _run_in_loop():
aioutils.run_coro_with_timeout(_saved_sleep_task(), loop, 0.1)
with pytest.raises(EventLoopBlocked), patch.object(aioutils, "_LOADED_SYSTEM_TIMEOUT", 0.0):
await loop.run_in_executor(None, _run_in_loop)
> assert task is not None
E assert None is not None
tests/utils/test_asyncio.py:139: AssertionError
Inspecting the test's code, it isn't actually doing much testing of zeroconf as opposed to asyncio; the only zeroconf code involved outside of the text fixture is one constant (that gets patched by the test) and one six-line function (zeroconf._utils.asyncio.run_coro_with_timeout) that doesn't appear to do anything deeply tricky. It strikes me as more likely that the test code is somehow holding asyncio wrong and causing flakiness (e.g., being surprised by a timeout that occurs later than expected due to scheduling delay) as opposed to asyncio being badly broken.
In Nixpkgs CI,
test_run_coro_with_timeoutis sporadically failing and then getting better without any apparent cause (for example, see https://hydra.nixos.org/job/nixpkgs/staging-next/python314Packages.zeroconf.x86_64-linux for the CI run history). I also couldn't immediately reproduce the failure locally.The error output is this:
Inspecting the test's code, it isn't actually doing much testing of zeroconf as opposed to asyncio; the only zeroconf code involved outside of the text fixture is one constant (that gets patched by the test) and one six-line function (
zeroconf._utils.asyncio.run_coro_with_timeout) that doesn't appear to do anything deeply tricky. It strikes me as more likely that the test code is somehow holding asyncio wrong and causing flakiness (e.g., being surprised by a timeout that occurs later than expected due to scheduling delay) as opposed to asyncio being badly broken.