[LVsarff]

Summary

asyncio.get_event_loop() is deprecated since Python 3.12 (and raises RuntimeError in Python 3.14 when no current loop exists). In coroutine contexts the recommended replacement is asyncio.get_running_loop(), which returns exactly the same loop with no deprecation.

This PR replaces the three usages in lib/crewai that are always executed inside a running event loop:

• src/crewai/tools/structured_tool.py — inside async def _arun, so a loop is always running
• src/crewai/rag/chromadb/client.py — inside async def _alocked, so a loop is always running
• src/crewai/utilities/streaming.py — the use_async=True branch of create_streaming_state, which is only reached from async kickoff paths (Crew.kickoff_async / streaming kickoff), so a loop is always running

Changes

One-line, behavior-identical replacement of asyncio.get_event_loop() with asyncio.get_running_loop() in each of the three files above.

Verification

• py_compile passes for all three files
• ruff check --no-fix reports no new findings on the changed lines (existing findings in these files are pre-existing and untouched)
• Call-path analysis confirms each site executes only inside a coroutine, so get_running_loop() returns the same loop get_event_loop() would

LLM disclosure

This change was prepared with the assistance of an AI coding agent and reviewed before submission. Per the repository's contribution guidelines, please add the llm-generated label to this PR if appropriate (I don't have permission to add labels myself).

---

Note

Low Risk
Mechanical asyncio API swap in paths that already require a running loop; no auth, data, or business-logic changes.

Overview
Replaces asyncio.get_event_loop() with asyncio.get_running_loop() in three places that always run inside an active event loop, avoiding Python 3.12+ deprecation and stricter behavior in 3.14 without changing runtime behavior at those call sites.

ChromaDB async locking (client._alocked) still runs cross-process lock enter/exit via run_in_executor, but now binds to the loop that is already running the coroutine.

Async structured tools (CrewStructuredTool.ainvoke) uses the same pattern when executing a synchronous tool function in a thread pool.

Async LLM streaming setup (create_streaming_state when use_async=True) captures that loop for thread-safe call_soon_threadsafe delivery of stream chunks into an asyncio.Queue.

^{Reviewed by Cursor Bugbot for commit 20d369f. Bugbot is set up for automated code reviews on this repo. Configure here.}

Fixes #8912

[strix-security]

Strix Security Review

✅ No open security findings.

PR summary: Replaces three deprecated `asyncio.get_event_loop()` calls with `asyncio.get_running_loop()` in the structured tool invocation, ChromaDB async lock, and async streaming state setup, to stay compatible with Python 3.12+ deprecation and 3.14 behavior.

Review summary

Reviewed all three changed lines. Each replacement is behavior-identical: every changed site executes inside a running event loop (_alocked is an async context manager, ainvoke is a coroutine, and the use_async=True branch of create_streaming_state is reached only from Crew.kickoff_async, Crew.akickoff, and run_for_each_async, all coroutines). No remaining get_event_loop usages in lib/crewai/src. No security controls were removed or weakened, no new input reaches a sink, and the only theoretical difference is a fail-closed RuntimeError in a hypothetical non-coroutine caller, which is a functional concern rather than an attacker-reachable vulnerability. No security issues found in the changed code.

_{Review 1 on this PR · 20d369f · requested Nov 1 12:59 UTC when the PR was opened}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[github-actions]

Thanks for the pull request.

First-time contributors need an associated open issue before we can review a PR.

1. Open an issue with a template, or pick an existing open one.
2. Open a new PR (or reopen this one) whose title or body mentions that issue, for example #123.

See the contributing guide.