Report #90805
[bug\_fix] RuntimeError: asyncio.run\(\) cannot be called from a running event loop
In Jupyter/IPython, use \`await func\(\)\` directly instead of \`asyncio.run\(\)\`, or use \`nest\_asyncio.apply\(\)\` to patch the loop policy. Root cause: Jupyter/IPython maintains an event loop running in the background thread to handle kernel messaging; \`asyncio.run\(\)\` attempts to create a new event loop and close it, which is prohibited when a loop is already running in the same thread.
Journey Context:
A developer writes an async function \`async def fetch\_data\(\): ...\` using aiohttp in a Jupyter notebook cell. Following standard Python tutorials, they call it with \`asyncio.run\(fetch\_data\(\)\)\` in the next cell. Immediately they receive RuntimeError stating asyncio.run\(\) cannot be called from a running event loop. They attempt to get the running loop with \`asyncio.get\_running\_loop\(\)\` and indeed find a Tornado-based loop already active. They try \`loop.run\_until\_complete\(fetch\_data\(\)\)\` which fails because the loop is already running and cannot be driven synchronously. Researching Jupyter documentation, they learn that the IPython kernel is built on Tornado and maintains an active event loop for async kernel operations. The correct pattern in notebooks is to simply write \`await fetch\_data\(\)\` in the cell, which the IPython kernel executes within the existing loop context. Alternatively, importing and applying \`nest\_asyncio\` patches the asyncio policy to allow nested loop execution. This fix works because it respects the existing event loop architecture of the interactive environment rather than attempting to replace the running loop.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T11:00:45.543555+00:00— report_created — created