RuntimeError: no running event loop
ID: python/runtimeerror-no-running-event-loop
Version Compatibility
| Version | Status | Introduced | Deprecated | Notes |
|---|---|---|---|---|
| 311 | active | — | — | — |
Root Cause
This error occurs when async code is called without a running event loop, or when asyncio.run() is called from within an already-running event loop. The root cause is almost always an incorrect boundary between synchronous and asynchronous code. Fixing it requires understanding which context you are in and using the appropriate pattern.
genericWorkarounds
-
93% success Use await directly when already inside an async context
If you are inside an async function (async def), simply 'await' the coroutine directly instead of using asyncio.run() or loop.run_until_complete(). For example, change 'asyncio.run(fetch_data())' to 'result = await fetch_data()'. If the calling function is not async, make it async and propagate await up the call chain.
Sources: https://docs.python.org/3/library/asyncio-task.html
-
85% success Use asyncio.get_event_loop() correctly based on your Python version and context
In Python 3.10+, asyncio.get_event_loop() emits a deprecation warning if no loop is running. Use 'asyncio.get_running_loop()' inside async code to get the current loop. For synchronous entry points, use 'asyncio.run(main())' as the single top-level call. For libraries that must support both sync and async, use 'loop.run_in_executor()' to bridge sync-to-async boundaries cleanly.
Sources: https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.get_running_loop
-
90% success Restructure code to maintain a clean sync/async boundary
Identify the single entry point where async begins (e.g., asyncio.run(main()) in a script, or the framework's async handler in FastAPI/Django). Keep all code above the boundary synchronous and all code below it async. Use 'loop.run_in_executor(None, sync_function)' to call synchronous blocking code from async code. Use 'asyncio.run()' only once at the top level.
Sources: https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.run_in_executor
Dead Ends
Common approaches that don't work:
-
Using nest_asyncio.apply() as a permanent fix in production code
72% fail
nest_asyncio monkey-patches asyncio to allow nested event loops, which masks the architectural problem and introduces subtle bugs. Nested loops can cause reentrancy issues where callbacks execute in unexpected order, leading to data races and deadlocks. It also prevents migration to newer Python async patterns and breaks structured concurrency guarantees.
-
Creating a new event loop with asyncio.new_event_loop() inside an async function
88% fail
Creating a second event loop inside an async context results in two competing loops. The new loop cannot run because the thread is already occupied by the outer loop. Calling loop.run_until_complete() on the new loop blocks the current thread and deadlocks the outer loop. This creates hangs that are difficult to diagnose.
-
Calling asyncio.run() inside a function that is already running within an event loop
95% fail
asyncio.run() creates a new event loop and runs it until completion. If called from within an already-running loop (e.g., inside a FastAPI endpoint, Django async view, or Jupyter cell), it raises 'RuntimeError: This event loop is already running'. asyncio.run() is designed as the top-level entry point, not for nested async calls.