-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Add Python 3.14 to the supported versions #1961
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
seratch
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While the installation now passes, some of tests are still failing
pyproject.toml
Outdated
| "openai>=2.2,<3", | ||
| "pydantic>=2.10, <3", | ||
| "openai>=2.6,<3", | ||
| "tiktoken>=0.12,<0.13", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these version upgrades are required to install deps
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need tiktoken?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tiktoken==0.11.0 coming from somewhere blocks pip install w/ python 3.14. need to check more deeply.
|
pyproject.toml
Outdated
| "openai>=2.2,<3", | ||
| "pydantic>=2.10, <3", | ||
| "openai>=2.6,<3", | ||
| "tiktoken>=0.12,<0.13", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need tiktoken?
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
I've removed tiktoken as it's no longer necessary to explicitly have |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ 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".
| # Python 3.14 no longer creates a default loop implicitly, so we inspect the running loop. | ||
| try: | ||
| loop = asyncio.get_running_loop() | ||
| except RuntimeError: | ||
| loop = None | ||
|
|
||
| if loop is not None: | ||
| # This method is only expected to run when no loop is already active. | ||
| raise RuntimeError( | ||
| "AgentRunner.run_sync() cannot be called when an event loop is already running." | ||
| ) | ||
|
|
||
| return asyncio.run( | ||
| self.run( | ||
| starting_agent, | ||
| input, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reusing sessions fails after switching run_sync to asyncio.run
The new implementation of AgentRunner.run_sync (lines 723‑740) always spins up a brand‑new event loop via asyncio.run. Many of the session implementations that users are expected to instantiate in synchronous code create loop‑bound primitives up front. For example, RedisSession and SQLAlchemySession both allocate an asyncio.Lock() in their constructors (src/agents/extensions/memory/redis_session.py:67, src/agents/extensions/memory/sqlalchemy_session.py:83). Those locks are bound to the thread’s default loop at construction time. Because asyncio.run now uses a different loop for the actual run, the first async with self._lock in get_items/add_items raises RuntimeError: <Lock> is bound to a different event loop, making Runner.run_sync(..., session=RedisSession(...)) or SQLAlchemySession unusable even on CPython 3.12/3.13. The previous get_event_loop().run_until_complete reused the same loop, so these sessions worked. To avoid regressing synchronous session support you need to keep using the thread’s default loop (e.g. reuse/initialize it once) or ensure these components are instantiated after the loop is created.
Useful? React with 👍 / 👎.
Update the package metadata and CI builds