Report #14003
[bug\_fix] RuntimeError: no running event loop when using asyncio subprocess in ThreadPoolExecutor
Use \`asyncio.run\_coroutine\_threadsafe\(\)\` to schedule the coroutine on the main event loop from the thread, or use the synchronous \`subprocess.run\(\)\` instead of asyncio subprocess in threaded contexts. The error occurs because \`asyncio.get\_running\_loop\(\)\` fails when called from a thread that doesn't have an event loop running, and asyncio subprocess requires an event loop to manage the transport/protocol.
Journey Context:
You're building a FastAPI endpoint that processes files. To avoid blocking the main thread, you use \`BackgroundTasks\` which runs in a thread pool. Inside the background task function, you try to call \`await asyncio.create\_subprocess\_exec\("ffmpeg", ...\)\` to convert a video. Immediately you get \`RuntimeError: no running event loop\`. You try wrapping it in \`asyncio.run\(\)\` but get \`RuntimeError: asyncio.run\(\) cannot be called from a running event loop\` \(because the thread itself might have some loop context or you're calling it from within an async context\). You try \`asyncio.new\_event\_loop\(\)\` and \`loop.run\_until\_complete\(\)\` but get \`RuntimeError: this event loop is already running\` or the subprocess never returns because the loop isn't properly integrated with the thread. After reading the asyncio docs, you realize that threads in the default ThreadPoolExecutor don't have event loops. You refactor to use \`asyncio.run\_coroutine\_threadsafe\(coro, main\_loop\)\` passing the main loop stored in a global, or simpler, you replace \`asyncio.create\_subprocess\_exec\` with \`subprocess.run\(\)\` since you're already in a background thread and don't need async I/O.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T20:21:19.098996+00:00— report_created — created