feat: add streaming support to OCI Generative AI provider

[fede-kamel]

Summary

• Add streaming text completion via OCI SSE events (stream=True)
• iter_stream() — sync generator yielding raw text chunks
• astream() — async generator wrapping sync stream via thread + queue
• _stream_chat_events holds ordered client lock for full stream duration
• SSE event parsing handles both string and mapping payloads

Depends on #4959 (basic text completion provider). Draft until #4959 merges.
Tracking issue: #4944

Diff breakdown

Change	Lines
completion.py (streaming methods)	+230
test_oci_streaming.py (4 unit tests)	+150
test_oci_integration_streaming.py (2 parametrized integration tests)	+40
Total	+420

Test plan

• 4 unit tests (mocked SSE events): stream call, iter_stream, astream, client lock
• Integration tests pass against 4 model families:
  • meta.llama-3.3-70b-instruct
  • cohere.command-r-plus-08-2024
  • google.gemini-2.5-flash
  • openai.gpt-5.2-chat-latest
• All 15 existing PR 1 unit tests still pass (no regressions)

[fede-kamel]

OCI GenAI PR series (tracking issue: #4944)

1. feat: add OCI Generative AI provider — basic text completion #4959 — Basic text completion
2. feat: add streaming support to OCI Generative AI provider #4961 — Streaming ← this PR
3. feat: add tool calling support to OCI Generative AI provider #4962 — Tool calling
4. feat: add structured output support to OCI Generative AI provider #4963 — Structured output
5. feat: add multimodal support to OCI Generative AI provider #4964 — Multimodal
6. feat: add OCI Generative AI embeddings provider #4966 — Embeddings
7. feat: add true async support to OCI provider via aiohttp #4982 — True async (aiohttp)

Depends on #4959.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds OCI as a native CrewAI LLM provider with optional SDK installation, configurable authentication, generic and Cohere request handling, synchronous/asynchronous completion, streaming, metadata tracking, and unit/live integration tests.

Changes

OCI provider integration

Layer / File(s)	Summary
OCI dependency, client setup, and routing lib/crewai/pyproject.toml, lib/crewai/src/crewai/llm.py, lib/crewai/src/crewai/utilities/oci.py, lib/crewai/src/crewai/llms/providers/oci/__init__.py	Adds the OCI optional dependency, SDK loading and authentication configuration, provider exports, and native model routing.
OCI completion requests and responses lib/crewai/src/crewai/llms/providers/oci/completion.py	Adds OCICompletion with environment-based configuration, generic/Cohere payloads, model-specific token handling, response parsing, hooks, metadata, and context-window selection.
Streaming and asynchronous execution lib/crewai/src/crewai/llms/providers/oci/completion.py	Adds synchronous streaming, asynchronous iteration through a background thread and queue, usage aggregation, and locked OCI client access.
Unit and live provider validation lib/crewai/tests/llms/oci/*	Adds mocked SDK fixtures and tests for routing, requests, responses, streaming, async calls, metadata, locking, and optional live OCI integration tests.

Sequence Diagram(s)

sequenceDiagram
  participant CrewAILLM
  participant OCICompletion
  participant OCIClient
  participant AsyncQueue
  CrewAILLM->>OCICompletion: call or astream with messages
  OCICompletion->>OCICompletion: normalize messages and build request
  OCICompletion->>OCIClient: execute chat or streaming request
  OCIClient-->>OCICompletion: response or streaming events
  OCICompletion->>AsyncQueue: forward asynchronous chunks
  OCICompletion-->>CrewAILLM: completion text, chunks, and metadata

Loading

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 78.43% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: adding streaming support to the OCI Generative AI provider.
Description check	✅ Passed	The description matches the changeset and correctly describes the OCI streaming implementation and tests.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

This PR is stale because it has been open for 45 days with no activity.

[fede-kamel]

Rebased onto current main and un-drafted — mergeable again. Streaming verified live against OCI on-demand (us-chicago-1), including SSE accumulation and usage metadata. Unit suite: 20 passed.

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (3)

lib/crewai/src/crewai/llms/providers/oci/completion.py (3)

209-231: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Unsupported message roles are silently dropped.

Messages whose role isn't user/system/assistant are skipped in both _build_generic_messages and _build_cohere_chat_history, logged only at debug level (invisible under default logging config). If upstream agent/task flows ever append tool-role entries to conversation history before native tool-calling support lands for OCI, those messages vanish without any visible signal, silently losing context sent to the model.

Also applies to: 233-260

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/crewai/src/crewai/llms/providers/oci/completion.py` around lines 209 -
231, Unsupported roles in _build_generic_messages and _build_cohere_chat_history
are dropped with only debug logging, potentially losing conversation context.
Update both methods to emit a visible warning when skipping unsupported roles,
including the role and enough message context to diagnose the issue; preserve
the existing supported-role mapping and skip behavior until OCI tool-role
support is implemented.

---

636-712: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

response_model is accepted but silently ignored.

call()/acall() accept response_model: type[BaseModel] | None but never reference it — passing it is a silent no-op that always returns plain text instead of a parsed model or a clear error. Given structured output is explicitly deferred to a later PR in this series (#4963), consider failing fast now rather than silently ignoring the argument, to avoid confusing callers who expect enforcement.

♻️ Suggested guard

     ) -> str | BaseModel | list[dict[str, Any]]:
+        if response_model is not None:
+            raise NotImplementedError(
+                "response_model is not yet supported by the OCI native provider."
+            )
         with llm_call_context():

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/crewai/src/crewai/llms/providers/oci/completion.py` around lines 636 -
712, Fail fast when a non-None response_model is supplied to call(), rather than
silently ignoring it; add the same validation to acall() or ensure it is
enforced before delegation, using a clear NotImplementedError or ValueError
stating structured outputs are unsupported. Keep the existing behavior unchanged
when response_model is None and reference the call() and acall() methods.

---

593-635: 🩺 Stability & Availability | 🔵 Trivial | 🏗️ Heavy lift

astream background thread has no cancellation path on early abandonment.

If the caller stops consuming the async generator early (e.g. break, timeout, cancellation), _producer's background thread keeps calling iter_stream to completion — continuing to hit the OCI API and (once the locking gap above is fixed) holding self._client_lock for the remaining stream duration, blocking any other call()/astream() on the same instance until the orphaned stream finishes server-side.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/crewai/src/crewai/llms/providers/oci/completion.py` around lines 593 -
635, Update astream and its _producer in the OCI provider to support
cancellation when the async generator is closed, cancelled, or abandoned: create
a stop event, have _producer and iter_stream consumption check it and stop
promptly, and ensure generator cleanup signals the event, closes/cancels the
underlying stream if supported, and joins or otherwise releases the worker
without blocking the event loop. Preserve normal completion and exception
propagation while preventing orphaned OCI requests and locks.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@lib/crewai/src/crewai/llms/providers/oci/completion.py`:
- Around line 347-357: Update _extract_usage and
_extract_usage_from_stream_event to read OCI reasoning-token usage from
reasoningTokens or completionTokensDetails.reasoningTokens, and include it as
reasoning_tokens when present. Preserve existing prompt, completion, and total
token extraction and ensure the resulting usage data reaches
_track_token_usage_internal for both non-streaming and streaming responses.
- Around line 555-591: Update iter_stream to hold self._client_lock throughout
response event consumption by reusing _stream_chat_events(chat_details), rather
than calling _chat and iterating response.data.events() outside the lock.
Preserve the existing event parsing, usage tracking, metadata updates, and final
response metadata assignment while consuming events from the locked generator;
apply the same locking correction to the related streaming paths identified by
_stream_chat_events, iter_stream, and the referenced call sites.

In `@lib/crewai/src/crewai/utilities/oci.py`:
- Around line 41-54: The SECURITY_TOKEN branch currently discards configured
passphrases when loading the private key. Update the private-key loading call in
the authentication logic to pass config.get("pass_phrase") instead of None,
preserving support for encrypted OCI session keys.

---

Nitpick comments:
In `@lib/crewai/src/crewai/llms/providers/oci/completion.py`:
- Around line 209-231: Unsupported roles in _build_generic_messages and
_build_cohere_chat_history are dropped with only debug logging, potentially
losing conversation context. Update both methods to emit a visible warning when
skipping unsupported roles, including the role and enough message context to
diagnose the issue; preserve the existing supported-role mapping and skip
behavior until OCI tool-role support is implemented.
- Around line 636-712: Fail fast when a non-None response_model is supplied to
call(), rather than silently ignoring it; add the same validation to acall() or
ensure it is enforced before delegation, using a clear NotImplementedError or
ValueError stating structured outputs are unsupported. Keep the existing
behavior unchanged when response_model is None and reference the call() and
acall() methods.
- Around line 593-635: Update astream and its _producer in the OCI provider to
support cancellation when the async generator is closed, cancelled, or
abandoned: create a stop event, have _producer and iter_stream consumption check
it and stop promptly, and ensure generator cleanup signals the event,
closes/cancels the underlying stream if supported, and joins or otherwise
releases the worker without blocking the event loop. Preserve normal completion
and exception propagation while preventing orphaned OCI requests and locks.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 396494e4-4357-474f-87ae-5a65ea12defc

📥 Commits

Reviewing files that changed from the base of the PR and between 85c467d and 7d65b7a.

📒 Files selected for processing (11)

• lib/crewai/pyproject.toml
• lib/crewai/src/crewai/llm.py
• lib/crewai/src/crewai/llms/providers/oci/__init__.py
• lib/crewai/src/crewai/llms/providers/oci/completion.py
• lib/crewai/src/crewai/utilities/oci.py
• lib/crewai/tests/llms/oci/__init__.py
• lib/crewai/tests/llms/oci/conftest.py
• lib/crewai/tests/llms/oci/test_oci.py
• lib/crewai/tests/llms/oci/test_oci_integration_basic.py
• lib/crewai/tests/llms/oci/test_oci_integration_streaming.py
• lib/crewai/tests/llms/oci/test_oci_streaming.py

[coderabbitai]

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Reasoning-token usage is never extracted, despite being a stated PR feature.

Neither _extract_usage nor _extract_usage_from_stream_event reads a reasoningTokens/completionTokensDetails.reasoningTokens field from OCI responses — both only surface prompt_tokens/completion_tokens/total_tokens. This contradicts the PR objectives ("Accumulation of reasoning-token usage details") and the author's own comment that streaming "accumulates reasoningTokens for reasoning-enabled models." Since reasoning_effort is sent on the request (line 303-304) for reasoning-capable models (GPT-5, Gemini 2.5, Cohere Command-A-Reasoning per the inline comment), but the corresponding usage accounting is dropped, callers get no visibility into reasoning-token spend for these models, and _track_token_usage_internal never sees a reasoning_tokens key to propagate downstream.

Also applies to: 428-436

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/crewai/src/crewai/llms/providers/oci/completion.py` around lines 347 -
357, Update _extract_usage and _extract_usage_from_stream_event to read OCI
reasoning-token usage from reasoningTokens or
completionTokensDetails.reasoningTokens, and include it as reasoning_tokens when
present. Preserve existing prompt, completion, and total token extraction and
ensure the resulting usage data reaches _track_token_usage_internal for both
non-streaming and streaming responses.

[coderabbitai]

🩺 Stability & Availability | 🔴 Critical | ⚡ Quick win

iter_stream doesn't hold the client lock for the full streaming duration.

_stream_chat_events (used by _stream_call_impl) correctly holds self._client_lock for the entire yield from response.data.events():

def _stream_chat_events(self, chat_details: Any) -> Any:
    with self._client_lock:
        response = self.client.chat(chat_details)
        yield from response.data.events()

But iter_stream (which astream() is built on) instead calls self._chat(chat_details), which releases the lock immediately after client.chat() returns, and then iterates response.data.events() completely unlocked:

response = self._chat(chat_details)      # lock released right after this returns
...
for event in response.data.events():     # unlocked iteration

Since _chat's own docstring states the OCI client "is not re-entrant," this means a concurrent call()/another astream()/iter_stream() on the same OCICompletion instance can invoke self.client while a previous iter_stream/astream call is still consuming its event stream — exactly the race condition the lock was introduced to prevent. This directly contradicts the PR's stated "ordered client locking for the full streaming duration" objective.

🔒 Proposed fix — reuse `_stream_chat_events` for lock consistency

     def iter_stream(
         self,
         messages: str | list[LLMMessage],
         tools: list[dict[str, BaseTool]] | None = None,
         callbacks: list[Any] | None = None,
         available_functions: dict[str, Any] | None = None,
         from_task: Task | None = None,
         from_agent: Agent | None = None,
     ) -> Any:
         """Yield raw text chunks from OCI without triggering tool recursion."""
         normalized_messages = self._normalize_messages(messages)
         chat_request = self._build_chat_request(normalized_messages, is_stream=True)
         chat_details = self._oci.generative_ai_inference.models.ChatDetails(
             compartment_id=self.compartment_id,
             serving_mode=self._build_serving_mode(),
             chat_request=chat_request,
         )
-        response = self._chat(chat_details)
         usage_data: dict[str, int] = {}
         response_metadata: dict[str, Any] = {}
 
-        for event in response.data.events():
+        for event in self._stream_chat_events(chat_details):
             event_data = self._parse_stream_event(event)

Also applies to: 723-727, 718-721

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/crewai/src/crewai/llms/providers/oci/completion.py` around lines 555 -
591, Update iter_stream to hold self._client_lock throughout response event
consumption by reusing _stream_chat_events(chat_details), rather than calling
_chat and iterating response.data.events() outside the lock. Preserve the
existing event parsing, usage tracking, metadata updates, and final response
metadata assignment while consuming events from the locked generator; apply the
same locking correction to the related streaming paths identified by
_stream_chat_events, iter_stream, and the referenced call sites.

[coderabbitai]

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Inspect the target file and nearby context
file="lib/crewai/src/crewai/utilities/oci.py"
wc -l "$file"
sed -n '1,220p' "$file"

# Search for OCI config/pass_phrase usage in the repo
rg -n "pass_phrase|load_private_key_from_file|SECURITY_TOKEN" lib/crewai/src -S

# If the OCI SDK is installed in the sandbox, inspect the signature/docs directly
python3 - <<'PY'
import inspect
try:
    import oci
    print("oci module:", oci.__file__)
    print("load_private_key_from_file signature:", inspect.signature(oci.signer.load_private_key_from_file))
    print("from_file signature:", inspect.signature(oci.config.from_file))
except Exception as e:
    print("OCI SDK inspection unavailable:", repr(e))
PY

Repository: crewAIInc/crewAI

Length of output: 3029

---

🌐 Web query:

OCI Python SDK load_private_key_from_file pass_phrase config key SecurityTokenSigner documentation

💡 Result:

In the OCI Python SDK, handling a private key with a passphrase is supported through the pass_phrase parameter, which is available in various signing and configuration methods [1][2][3]. load_private_key_from_file The oci.signer.load_private_key_from_file(filename, pass_phrase=None) function is used to load a private key from a file on disk [2][3]. If your private key is encrypted, you must provide the passphrase via the pass_phrase argument to successfully load and decrypt the key [2][3]. Configuration File When using the OCI configuration file (typically ~/.oci/config), you can specify the passphrase by adding a pass_phrase key to your profile [4][5]. The SDK automatically reads this value if present. This is particularly useful when using oci.config.from_file() to load your configuration, as the SDK handles the passphrase integration when creating signers [1][6]. Signer and SecurityTokenSigner - Signer: The standard oci.signer.Signer class accepts a pass_phrase argument in its constructor [2][6]. If you are creating a signer manually, you can pass the passphrase directly there [1][6]. - SecurityTokenSigner: The oci.auth.signers.SecurityTokenSigner is designed for scenarios where the API key is a token (such as for instance principals or service-to-service authentication) [7][8]. Unlike the standard Signer used for user-based authentication, SecurityTokenSigner expects the caller to provide the token and the pre-loaded private key directly [7]. If you are using this class, you would typically load the private key yourself using load_private_key_from_file (with the pass_phrase provided) before passing the key object to the SecurityTokenSigner constructor [2][3][7].

Citations:

• 1: https://oracle-cloud-infrastructure-python-sdk.readthedocs.io/en/latest/raw-requests.html
• 2: https://docs.oracle.com/en-us/iaas/tools/python/latest/api/signing.html
• 3: https://oracle-cloud-infrastructure-python-sdk.readthedocs.io/en/latest/api/signing.html
• 4: https://docs.oracle.com/en-us/iaas/tools/python/latest/configuration.html
• 5: https://github.com/oracle/oci-python-sdk/blob/master/src/oci/config.py
• 6: https://github.com/oracle/oci-python-sdk/blob/master/src/oci/signer.py
• 7: https://github.com/oracle/oci-python-sdk/blob/9b6357cb/src/oci/auth/signers/security_token_signer.py
• 8: https://github.com/oracle/oci-python-sdk/blob/master/docs/api/signing.rst

---

Pass pass_phrase through for SECURITY_TOKEN private keys. load_private_key_from_file(key_file, None) drops support for encrypted OCI keys; use config.get("pass_phrase") so passphrase-protected session keys can authenticate.

🧰 Tools

🪛 ast-grep (0.44.1)

[warning] 48-48: File path is request-/variable-derived; validate and normalize to prevent path traversal.
Context: open(security_token_file, encoding="utf-8")
Note: [CWE-22] Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').

(open-filename-from-request)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/crewai/src/crewai/utilities/oci.py` around lines 41 - 54, The
SECURITY_TOKEN branch currently discards configured passphrases when loading the
private key. Update the private-key loading call in the authentication logic to
pass config.get("pass_phrase") instead of None, preserving support for encrypted
OCI session keys.

[coderabbitai]

🧹 Nitpick comments (3)

lib/crewai/tests/llms/oci/test_oci_streaming.py (3)

20-20: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Move import json to the top of the module.

The import json statement inside _make_fake_stream_event is non-idiomatic. Python best practices recommend top-of-file imports.

♻️ Suggested refactor

 from __future__ import annotations
 
+import json
 from unittest.mock import MagicMock
@@
-    import json
    event = MagicMock()

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/crewai/tests/llms/oci/test_oci_streaming.py` at line 20, Move the json
import from inside _make_fake_stream_event to the module-level import section at
the top of the file, and remove the nested import from the function.

Source: Coding guidelines

---

51-53: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Extract the StreamOptions mock into a shared fixture.

The StreamOptions mock setup is duplicated across three tests (lines 51-53, 84-86, 114-116). Extracting it into a fixture (or extending the existing patch_oci_module fixture) would reduce duplication and ensure consistency.

♻️ Suggested refactor

+# In conftest.py or a local fixture:
+@pytest.fixture(autouse=True)
+def mock_stream_options(patch_oci_module):
+    patch_oci_module.generative_ai_inference.models.StreamOptions = MagicMock(
+        side_effect=lambda **kw: MagicMock(**kw)
+    )
+
 # Then remove these blocks from each test:
-    patch_oci_module.generative_ai_inference.models.StreamOptions = MagicMock(
-        side_effect=lambda **kw: MagicMock(**kw)
-    )

Also applies to: 84-86, 114-116

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/crewai/tests/llms/oci/test_oci_streaming.py` around lines 51 - 53,
Extract the duplicated StreamOptions MagicMock setup from the tests into a
shared fixture or extend the existing patch_oci_module fixture. Configure
StreamOptions once with the current side_effect behavior, then have all three
streaming tests reuse that fixture and remove their local setup.

Source: Coding guidelines

---

129-158: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Lock test accesses internal implementation details.

test_oci_stream_chat_events_holds_client_lock directly tests _client_lock and _stream_chat_events rather than observable behavior. Per coding guidelines, unit tests should focus on behavior rather than implementation details. That said, lock-holding semantics are inherently internal, so this is a reasonable trade-off — just flagging for awareness.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/crewai/tests/llms/oci/test_oci_streaming.py` around lines 129 - 158, The
lock test intentionally verifies internal lock-holding semantics, so retain it
but clearly document that this is an accepted exception to behavior-focused
testing guidelines. In test_oci_stream_chat_events_holds_client_lock, keep the
assertions around _client_lock and _stream_chat_events, and add a concise
comment or docstring explaining why these implementation details must be tested.

Source: Coding guidelines

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@lib/crewai/tests/llms/oci/test_oci_streaming.py`:
- Line 20: Move the json import from inside _make_fake_stream_event to the
module-level import section at the top of the file, and remove the nested import
from the function.
- Around line 51-53: Extract the duplicated StreamOptions MagicMock setup from
the tests into a shared fixture or extend the existing patch_oci_module fixture.
Configure StreamOptions once with the current side_effect behavior, then have
all three streaming tests reuse that fixture and remove their local setup.
- Around line 129-158: The lock test intentionally verifies internal
lock-holding semantics, so retain it but clearly document that this is an
accepted exception to behavior-focused testing guidelines. In
test_oci_stream_chat_events_holds_client_lock, keep the assertions around
_client_lock and _stream_chat_events, and add a concise comment or docstring
explaining why these implementation details must be tested.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 78010feb-b285-4624-a509-d5dd3cc86d39

📥 Commits

Reviewing files that changed from the base of the PR and between 7d65b7a and 3ed4412.

📒 Files selected for processing (5)

• lib/crewai/src/crewai/llms/providers/oci/completion.py
• lib/crewai/tests/llms/oci/conftest.py
• lib/crewai/tests/llms/oci/test_oci_integration_basic.py
• lib/crewai/tests/llms/oci/test_oci_integration_streaming.py
• lib/crewai/tests/llms/oci/test_oci_streaming.py

🚧 Files skipped from review as they are similar to previous changes (4)

• lib/crewai/tests/llms/oci/test_oci_integration_streaming.py
• lib/crewai/tests/llms/oci/conftest.py
• lib/crewai/tests/llms/oci/test_oci_integration_basic.py
• lib/crewai/src/crewai/llms/providers/oci/completion.py