Studio: don't apply nest_asyncio on plain CLI starts (breaks asyncio on Python 3.14+)#7186
Conversation
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Code Review
This pull request modifies studio/backend/run.py to conditionally apply nest_asyncio only when an asyncio event loop is already running. This prevents potential issues on Python 3.14+ where nest_asyncio patches can break asyncio.current_task() during a plain CLI start. There are no review comments, so I have no additional feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2a61a67ccb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| pass | ||
| else: | ||
| import nest_asyncio | ||
| nest_asyncio.apply() |
There was a problem hiding this comment.
Avoid applying nest_asyncio on Python 3.14 notebooks
When Studio is launched from IPython/Jupyter or another embedder on Python 3.14+, get_running_loop() succeeds, so this branch still calls nest_asyncio.apply(). That patch is global and also affects the uvicorn loop created below in the background thread, so the anyio/thread-pool current_task() failure described in the commit still occurs for notebook/embedded starts even though the package allows Python <3.15. Gate this branch by Python version or avoid patching the server loop.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 5bc376d: gated the apply() on sys.version_info < (3, 14), so nest_asyncio is never touched on 3.14+ (CLI or notebook). Since apply() patches globally it also broke the background uvicorn loop, so notebook/embedded starts 500'd on 3.14 too; skipping it there returns them to 200 while <=3.13 keeps the existing running-loop behavior unchanged. Verified across Python 3.9-3.14.
|
@codex review |
1 similar comment
|
@codex review |
|
Codex Review: Didn't find any major issues. Delightful! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
@codex review |
|
Codex Review: Didn't find any major issues. 👍 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
@danielhanchen LGTM. |
Problem
run.pycallsnest_asyncio.apply()unconditionally at startup. On Python 3.14, asyncio's task tracking moved into C (asyncio.current_task()reads C-level state that nest_asyncio's patched task step never sets), so with the patch appliedcurrent_task()returnsNoneinside every request coroutine. anyio then fails on any thread-pool hop — including StaticFiles serving every frontend asset:Every request 500s; Studio is unusable on 3.14. Minimal repro (Python 3.14.6, anyio 4.13):
nest_asyncio is archived upstream, so no fix is coming on its side.
Change
Only apply nest_asyncio when the current thread already has a running event loop — the Colab/IPython case it exists for. A plain CLI start has nothing to nest and stays unpatched, which is exactly the environment where Python 3.14 users hit the crash. Notebook behavior on <= 3.13 is unchanged.
Tested
On Python 3.14.6: backend starts,
/and/assets/*.js(the previously-crashing StaticFiles thread-pool path) return 200, API routes respond normally. Repro script above confirms the failure mode and that skipping the patch avoids it.