pytest-timeout leaves asyncio tasks running after test timeout

Short answer

No — pytest-timeout does not, and by design cannot safely, cancel asyncio tasks when it fires. It interrupts the test by raising TimeoutError in the executing frame (via SIGALRM on POSIX or a watchdog thread on Windows). Any tasks the test created with asyncio.create_task() keep being scheduled on the event loop after the test is reported as failed. Automatic cancellation would need to be an opt-in feature implemented cooperatively with pytest-asyncio, not a default.

Why the tasks survive

The signal handler (or watchdog) raises an exception at whatever bytecode the main thread happens to be executing. It has no knowledge of the event loop, so it never calls task.cancel(). Two consequences follow:

• Pending tasks stay in the loop's ready queue. If the loop is closed by a fixture teardown without shutdown, you get "Task was destroyed but it is pending" warnings, leaked connections, or hangs in later tests.
• On POSIX, SIGALRM only reaches the main thread. If the test runs its loop (or a blocking call) in a worker thread, the timeout may not even interrupt the right frame.

Should the plugin cancel tasks automatically?

Not by default. Cancelling every task on timeout injects CancelledError into arbitrary finally blocks and fixture teardown, which would break existing suites that rely on normal cleanup running to completion. It can also mask the original timeout if a cancellation error propagates first. That is why the conservative behavior — fail the test, leave cleanup to the test/fixtures — is the current default.

What a cross-platform mechanism would look like

A reliable implementation needs cooperation from the async plugin, because only it knows which loop belongs to the test:

1. On timeout, before reporting failure, locate the test's event loop (via pytest-asyncio's loop tracking, not asyncio.get_event_loop(), which is unreliable across threads).
2. Call asyncio.all_tasks(loop), cancel each, and await them with a short grace period — essentially what loop.shutdown_asyncgens() plus a manual cancel-and-gather does.
3. Only then raise/record the TimeoutError, so the failure reason stays accurate.

This works on Windows too, because cancellation is requested on the loop object rather than by interrupting bytecode — the watchdog thread just needs a thread-safe handle to the loop (loop.call_soon_threadsafe).

Backward-compatible configuration

An opt-in ini option would preserve existing behavior, e.g.:

# pytest.ini
[pytest]
timeout = 30
timeout_cancel_asyncio = true   # proposed, default false
timeout_cancel_grace = 2        # seconds to wait for cancelled tasks

Defaulting to off keeps every current suite unchanged; users with leaky async tests opt in explicitly.

What to do today, without plugin changes

Make the tests cancellation-aware so the plugin's blunt instrument is never the cleanup path:

import asyncio, pytest

@pytest.mark.asyncio
async def test_worker():
    async with asyncio.timeout(5):   # Python 3.11+; else asyncio.wait_for
        await run_worker()

Also ensure fixtures close loops and connections in finally blocks, and consider anyio-style cancel scopes if you need structured cleanup.

Verify the leak yourself

import asyncio, pytest

@pytest.mark.asyncio
async def test_leak():
    t = asyncio.create_task(asyncio.sleep(60))
    await asyncio.sleep(30)  # killed by --timeout=1 first

Run pytest --timeout=1 -s and add a finalizer that prints t.done() — you will see the task still pending. Also confirm with pip show pytest-timeout pytest-asyncio which versions and which asyncio_mode you are on, since loop ownership differs between strict and auto modes. If your traceback shows asyncio.TimeoutError rather than the plugin's TimeoutError, the timeout is coming from your own wait_for, not the plugin — that distinction changes the fix.