Studio: correct anyio<4.14 comments to the real #6483 cause (4.14/Py3.13 streaming cancel-scope bug) - #6581
Conversation
#6579 reworded these comments to attribute the failure to a half-resolved install and claimed a clean 4.14 is fine on 3.13. That is wrong: #6483 is a genuine anyio 4.14 + Python 3.13 regression. 4.14 added a per-task cancel scope in its asyncio backend (TaskHandle/_run_coro) that gets exited in the wrong task under starlette's collapsing task group, raising the cancel-scope RuntimeError on streaming; 4.13 has no such code and is unaffected (the reporter confirmed 4.13.0 fixes it). The TaskHandle ImportError is only the secondary macOS-arm symptom from the mlx-vs-cap version fight. Comments only.
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the explanatory comments in the backend requirements and constraints files regarding the anyio<4.14.0 dependency cap. The updated comments clarify that anyio 4.14 causes a RuntimeError related to asyncio cancel scopes on Python 3.13 during streaming responses under Starlette. I have no feedback to provide as there are no review comments.
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.
2 participants
Follow-up correcting comments merged in #6579. Comments only, no version changes.
#6579 reworded the
anyio<4.14pin comments to say a clean 4.14 is fine on 3.13 and that the failure is just a half-resolved install. That is inaccurate. #6483 is a genuine anyio 4.14 + Python 3.13 regression, not an install artifact.What actually breaks (#6483)
From the reporter's crash log (clean 4.14.0, Python 3.13, Apple Silicon), a streaming
/v1/chat/completionsraises:anyio 4.14 added
TaskHandle, andTaskHandle.__init__creates a per-taskCancelScopethat_run_coroenters withwith self._cancel_scope:. Under starlette's collapsing task group on the asyncio backend + Python 3.13, that scope is exited in a different task than it was entered, tripping anyio's host-task check. 4.13 has none of this code (noTaskHandle/_run_coro), so it is unaffected - the reporter confirmedanyio==4.13.0fixes it. Same Py3.13 cancel-scope class seen upstream (e.g. encode/httpx#3728).The
TaskHandleImportError seen in CI is a separate, secondary symptom: on macOS-arm the cap fights mlx'sanyio>=4.14, leaving a half-resolved 4.14/4.13 anyio. That is real too, but it is not what #6483 is about.Why the pin stays
The
<4.14cap is the correct mitigation for the real upstream bug; this PR only fixes the comments so the rationale is accurate (and so nobody un-pins thinking 4.14 is fine on 3.13). The actual fix belongs upstream in anyio.