RuntimeError: Event loop is closed

What this error actually means

Every asyncio primitive — a task, a transport, a lock, a connection pool — is bound to the loop that created it. Closing a loop does not unbind them; it only makes them unusable. This error means something still holding a reference to a closed loop tried to use it, most often to schedule a callback or to tear down a socket.

The single biggest source is `asyncio.run`. It creates a fresh loop, runs one coroutine, then cancels remaining tasks, shuts down async generators and closes the loop. Anything you created inside that call and stored somewhere outside it — a client session, an engine, a pool cached on a module-level variable — now points at a dead loop. The second `asyncio.run` in the same process gets a different loop, and the cached object raises the moment it touches the old one.

The other common shape is an object whose `__del__` needs the loop. When the garbage collector finalises a transport or a subprocess after shutdown, the finaliser tries to schedule cleanup on a loop that no longer exists. Python prints `Exception ignored in: <function ... .__del__>` — which is why this frequently appears *after* your program has finished, with no relation to any request, and is so often dismissed as cosmetic. It is not: it usually means a connection was never closed properly.

How to diagnose it

import asyncio; print(id(asyncio.get_running_loop()))

grep -rn 'asyncio.run(\|run_until_complete(\|new_event_loop(' --include='*.py' .

PYTHONASYNCIODEBUG=1 python -X dev app.py

print([t.get_coro() for t in asyncio.all_tasks() if not t.done()])

The fix

Have exactly one `asyncio.run` per process, at the top. Everything async lives inside it, and synchronous callers are pushed to the edges. If a sync function needs async work, restructure so the async side owns the entry point rather than wrapping `asyncio.run` deeper in the stack — that wrapping is what multiplies loops.

Create loop-bound clients inside the loop and close them inside it too. `async with aiohttp.ClientSession() as session:` around the lifetime of the work, or a lifespan hook in FastAPI/Starlette that creates the client on startup and awaits its `aclose()` on shutdown. Lazily caching a client on a module global is exactly the pattern that breaks.

Await or cancel every background task before the loop closes. Keep strong references to tasks you create, then `await asyncio.gather(*tasks, return_exceptions=True)` — or cancel them and await the cancellation — in your shutdown path. A task you never reference can also be garbage collected mid-flight, which is a separate and worse bug.

For the finaliser noise, close resources explicitly rather than leaving them to `__del__`. Every transport, subprocess and connection pool should have a deterministic `close()`/`aclose()` awaited before shutdown. If the message persists, the remaining offender is almost always a library client you construct but never close.

In tests, match fixture scope to loop scope. With `pytest-asyncio`, a client fixture must be function-scoped unless the loop is session-scoped too; mixing the two is the standard cause of "the second test always fails".

# Module-level client captures whichever loop ran first
_client = None

async def fetch(url):
    global _client
    if _client is None:
        _client = httpx.AsyncClient()      # bound to this loop forever
    return await _client.get(url)

def sync_fetch(url):
    return asyncio.run(fetch(url))         # second call -> Event loop is closed

# One loop; the client lives and dies inside it
async def main(urls):
    async with httpx.AsyncClient(timeout=5.0) as client:
        tasks = [asyncio.create_task(client.get(u)) for u in urls]
        try:
            return await asyncio.gather(*tasks)
        finally:
            for t in tasks:
                t.cancel()

asyncio.run(main(urls))

How to stop it coming back

• Treat `asyncio.run` as a `main()` construct: one per process, never inside a library function or a helper
• Own the lifecycle of every client in a lifespan or startup/shutdown hook rather than lazily on first use
• Keep strong references to created tasks and drain them on shutdown; a fire-and-forget task is an untracked resource
• Run CI with `-X dev` and `PYTHONASYNCIODEBUG=1` so unclosed resources and slow callbacks fail loudly in development
• Never silence `Exception ignored in __del__` — it is a real unclosed resource reported at the least convenient moment

FAQ

Related

Other errors engineers hit next to this one

• ERROR: canceling statement due to statement timeout
• ERROR: could not serialize access due to concurrent update
• ERROR: current transaction is aborted, commands ignored until end of transaction block
• ERROR: duplicate key value violates unique constraint
• Deep OFFSET pagination getting slower every page
• ERROR: canceling statement due to lock timeout (ALTER TABLE)
• ERROR: canceling statement due to conflict with recovery
• Threads blocked forever on a ReentrantLock with no deadlock reported