Event Loop Is Closed: Fix asyncio Reuse After Close

You wrote an async script, it ran fine once, then you refactored it and now every run ends with RuntimeError: Event loop is closed. Nothing in the traceback points at your business logic. The failure sits one layer below it, in the machinery that drives your coroutines.

The confusion is understandable because the loop is invisible most of the time. asyncio.run() hides it: it builds a loop, runs your coroutine, then tears the loop down. That teardown is permanent. A closed loop never reopens, yet a surprising amount of code keeps a reference to it — a cached loop in a global, an aiohttp session bound to the old loop, a test fixture shared across cases — and tries to schedule one more callback on it.

This article traces each trigger to its fix. You'll see why asyncio.run() closes its loop by design, how reuse-after-close actually happens in real code, the exact order for shutting down aiohttp sessions, what the Windows Proactor warning means, and why libraries must stop calling get_event_loop(). By the end you'll have a small set of patterns — one loop per run, cleanup before close, explicit loop passing — that make this error disappear for good.

asyncio.run() Closes Its Loop: Why the Second Call Fails

asyncio.run() is a three-act play: it creates a new event loop, runs your coroutine to completion on it, then shuts down async generators, cancels leftovers, and closes the loop. Closing is a one-way door. The loop releases its selector and file descriptors and flips an internal flag, and every scheduling method starts with a check that raises RuntimeError: Event loop is closed when that flag is set. There is no reopen, no reset, no revive.

That finality surprises people because the loop object still exists. Your variable still points at it, its methods still autocomplete, and the error only appears when you actually schedule something — run_until_complete, create_task, or call_soon. So code that cached the loop keeps working right up until the first reuse, which can be minutes later in a worker or the second test in a suite.

The rule is simple: one asyncio.run() call owns exactly one loop for exactly one run. Sequential jobs mean sequential asyncio.run() calls, each with its own fresh loop. If you manage loops by hand with new_event_loop(), construct the loop where you use it and close it when you're done. Never stash a loop in a module global, a default argument, or a singleton and expect it to survive across runs. The demo below shows the failure and the fix side by side.

import asyncio

async def fetch(n):
    await asyncio.sleep(0.01)
    return n * 2

# Correct: one asyncio.run() per entry point, fresh loop each time
print(asyncio.run(fetch(21)))

# The bug: keeping a loop reference and reusing it after close
loop = asyncio.new_event_loop()
print(loop.run_until_complete(fetch(10)))
loop.close()
print("closed:", loop.is_closed())
try:
    loop.run_until_complete(fetch(1))
except RuntimeError as exc:
    print("RuntimeError:", exc)

# Fix: build a new loop instead of reviving the dead one
loop2 = asyncio.new_event_loop()
try:
    print(loop2.run_until_complete(fetch(3)))
finally:
    loop2.close()

Reusing Loops and Clients After Close: the Real Trigger

Reuse-after-close rarely looks like reuse. It looks like a helper that takes a loop parameter defaulting to a stale global, a class that stores self.loop at construction and schedules tasks in a later method, or a test fixture with module scope shared across cases. The first user of the cached loop closes it — or asyncio.run() closes its own loop while the cached reference still points at it — and the next user inherits a corpse.

The tell is timing: the first run works and later ones fail, or tests pass in isolation and fail as a suite. When you see that pattern, hunt for stored loops. Search for get_event_loop, new_event_loop, and loop parameters kept beyond a single call. A loop should live exactly as long as the run it serves, constructed at the top of the entry point and closed in a finally block.

When you must own the loop yourself — embedding asyncio in a sync codebase, for example — wrap construction, use, and teardown in one helper like the runner below. It builds the loop, sets it as current, runs the coroutine, shuts down async generators, closes the loop, and clears the thread-local slot. Every call gets a virgin loop, so close-races between sequential runs become impossible by construction.

import asyncio

async def work(tag):
    await asyncio.sleep(0.01)
    return f"done-{tag}"

def run_coro(coro):
    loop = asyncio.new_event_loop()
    try:
        asyncio.set_event_loop(loop)
        return loop.run_until_complete(coro)
    finally:
        try:
            loop.run_until_complete(loop.shutdown_asyncgens())
        except RuntimeError:
            pass
        loop.close()
        asyncio.set_event_loop(None)

print(run_coro(work("a")))
print(run_coro(work("b")))

aiohttp Cleanup Order: Close Sessions Before the Loop Dies

aiohttp sessions are loop-bound. The ClientSession's connector schedules DNS refreshes, connection reaps, and cleanup callbacks on the running loop at creation time. If you create the session at import time or in a prior run, those callbacks belong to a loop that asyncio.run() has since closed. The next request — or even garbage collection of the old connector — tries to schedule on the dead loop and raises.

The fix is ownership discipline: create the session inside the coroutine that asyncio.run() executes, and await session.close() in a finally block before that coroutine returns. The async with ClientSession() pattern does this automatically. Closing inside the run guarantees the connector's teardown callbacks execute on the still-live loop, leaving nothing dangling for the garbage collector to trip over.

Order matters beyond sessions too. Cancel or await background tasks first, then close sessions and connection pools, then let asyncio.run() close the loop. Reversing that order — loop first, sessions second — is the classic source of unclosed-connector warnings paired with loop-closed errors. The snippet below models the safe shape with a stand-in session so you can run it without installing anything.

import asyncio

class FakeSession:
    def __init__(self):
        self.closed = False

    async def get(self, url):
        await asyncio.sleep(0.01)
        return f"200 {url}"

    async def close(self):
        await asyncio.sleep(0)
        self.closed = True

async def main():
    session = FakeSession()
    try:
        print(await session.get("https://example.com"))
    finally:
        await session.close()
    return session.closed

print("session closed cleanly:", asyncio.run(main()))

Windows Proactor Warning: a Different Loop, Same Error

Windows runs asyncio on the Proactor event loop by default, while Linux and macOS use selector-based loops. The Proactor model doesn't implement selector APIs like add_reader() and add_writer(), so libraries written against selectors emit warnings or fail outright on Windows. You'll see loop-closed errors nearby when fallback code constructs and discards loops while probing for a working policy.

The pragmatic fix is to set the policy once at startup, and only on Windows. Guard it with a sys.platform check so POSIX behavior stays untouched: on win32, install asyncio.WindowsSelectorEventLoopPolicy() before any loop is created. That gives subprocess and selector support back at the cost of Proactor-specific features like overlapped I/O, which most HTTP client code doesn't need.

Better yet, write policy-agnostic code so the platform default stops mattering. Build loops with asyncio.new_event_loop(), avoid add_reader/add_writer in application code, and prefer high-level APIs like asyncio.subprocess and streams. The helper below runs anywhere without touching policy internals, and it keeps working whether the default underneath is Proactor or selector. That portability also simplifies onboarding: new hires run the same entry point on any laptop without platform-specific setup docs.

import asyncio
import sys

print("platform:", sys.platform)

async def ping():
    await asyncio.sleep(0.01)
    return "pong"

def portable_run(coro):
    loop = asyncio.new_event_loop()
    try:
        asyncio.set_event_loop(loop)
        return loop.run_until_complete(coro)
    finally:
        loop.close()
        asyncio.set_event_loop(None)

print(portable_run(ping()))

Never Call get_event_loop() in Libraries: Pass Loops Explicitly

asyncio.get_event_loop() is a trap in shared code. At module scope or in a sync helper it returns the thread-local current loop — or creates one with deprecation warnings on newer Pythons — which may be closed, foreign to the caller's thread, or simply not the loop that's actually running the caller's coroutine. Libraries that stash that value bake one context's loop into every future call.

The replacement depends on context. Inside a coroutine, asyncio.get_running_loop() always returns the loop that's executing you — no guessing, no thread-local roulette. In sync code that must bridge into async, accept an explicit loop parameter or, cleaner still, expose the coroutine and let the caller drive it with asyncio.run(). Both shapes keep loop ownership with the entry point instead of the library.

This also kills a whole class of test bugs. Suites that call helpers across cases with different loops stop flaking once helpers quit caching. Lint for get_event_loop in library paths and rewrite each hit as get_running_loop or an injected parameter. The snippet shows the pattern: the helper reads the running loop at call time, so it works under any runner, in any thread, on any run — no hidden coupling to whoever created a loop first.

import asyncio

# Good library shape: use the running loop, or take one as an argument
async def library_call(url, loop=None):
    running = loop or asyncio.get_running_loop()
    await asyncio.sleep(0.01)
    return f"fetched {url} on {id(running)}"

async def main():
    first = await library_call("https://a.example")
    second = await library_call("https://b.example")
    return first, second

for line in asyncio.run(main()):
    print(line)

One Loop Per Thread: the Pattern That Ends the Error

Event loops are not thread-safe and not shareable. Each thread that runs asyncio needs its own loop, created in that thread and closed in that thread. Sharing one loop across threads means callbacks fire on the wrong thread, and closing it in one thread pulls the rug out from tasks running in another — surfacing as loop-closed errors far from the actual close call.

The clean shape is one asyncio.run() per thread, as the snippet shows. Each thread entry point calls asyncio.run() with its own coroutine, so loop construction, execution, and teardown all happen on the owning thread with zero sharing. Results flow back through thread-safe channels like queues or pre-sized dicts written before join.

Mind the lifecycle edges. Join every async thread before process exit or the interpreter may tear down loops mid-callback. Keep sessions and clients inside the thread's coroutine so cleanup runs on the owning loop. And never call set_event_loop with a loop from another thread — the thread-local slot exists precisely to keep each thread's loop private. Follow those rules and threaded asyncio stays boring, which is exactly what you want. The pattern scales cleanly too: adding a ninth or tenth worker means spawning one more thread with its own run, not re-architecting shared state.

import asyncio
import threading

async def job(n):
    await asyncio.sleep(0.01)
    return n + 1

def thread_main(n, out):
    out[n] = asyncio.run(job(n))  # fresh loop owned by this thread

out = {}
threads = [threading.Thread(target=thread_main, args=(i, out)) for i in range(3)]
for t in threads:
    t.start()
for t in threads:
    t.join()
print(out)