chore(deps): various vulnerabilities resolution #3280
Conversation
WalkthroughDependency/version constraint updates across many packages' pyproject.toml files: added explicit transitive constraints (aiohttp, protobuf, and a few others), bumped several package versions (anthropic, vcrpy, transformers, tokenizers, requests, mcp), and one test changed an OpenAI tool-call type import/name. No runtime code changes beyond test updates. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed everything up to dee2c85 in 1 minute and 7 seconds. Click for details.
- Reviewed
209lines of code in9files - Skipped
8files when reviewing. - Skipped posting
9draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. packages/opentelemetry-instrumentation-anthropic/pyproject.toml:32
- Draft comment:
Added security constraints for transitive dependencies (aiohttp and protobuf) and bumped the anthropic dependency version to >=0.64.0. Verify that these version updates are compatible with the rest of the instrumentation. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is asking the PR author to verify compatibility of version updates, which is against the rules. It does not provide a specific suggestion or point out a specific issue with the code.
2. packages/opentelemetry-instrumentation-bedrock/pyproject.toml:31
- Draft comment:
Bumped the anthropic dependency to >=0.64.0. Ensure that this upgrade does not break any existing functionality in the Bedrock instrumentation. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is asking the PR author to ensure that the upgrade does not break existing functionality, which is against the rules. It does not provide a specific suggestion or point out a specific issue with the code.
3. packages/opentelemetry-instrumentation-langchain/pyproject.toml:32
- Draft comment:
Added security constraints (aiohttp and protobuf) and updated the anthropic version from ^0.51.0 to ^0.64.0. Confirm that these changes align with the Langchain instrumentation requirements. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is asking the PR author to confirm alignment with Langchain instrumentation requirements, which is against the rules. It also mentions dependency changes, which should not be commented on unless they are recognized and relevant.
4. packages/opentelemetry-instrumentation-llamaindex/pyproject.toml:32
- Draft comment:
Added security constraints for transitive dependencies (aiohttp and protobuf) to address vulnerabilities. Verify these versions are compatible with the LlamaIndex instrumentation. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%The comment is asking the PR author to verify compatibility of the updated dependencies with a specific part of the codebase. This falls under the rule of not asking the author to double-check things or ensure compatibility, which is not allowed.
5. packages/opentelemetry-instrumentation-openai/pyproject.toml:32
- Draft comment:
Introduced security constraints (aiohttp and protobuf) and updated the requests dependency to ^2.32.4. Ensure OpenAI instrumentation works with these dependency upgrades. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%The comment is discussing dependency changes and asking to ensure that OpenAI instrumentation works with these upgrades. This falls under the rule of not commenting on dependency changes or asking the author to ensure something works, which is not allowed.
6. packages/opentelemetry-instrumentation-openai/tests/traces/test_chat.py:7
- Draft comment:
Replaced ChatCompletionMessageFunctionToolCall with ChatCompletionMessageToolCall in tests. This change reflects an upstream API update—ensure that the new import and instantiation work correctly with the OpenAI library version in use. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative and asks the PR author to ensure that the change works correctly with the library version in use. It doesn't provide a specific suggestion or point out a potential issue with the code itself.
7. packages/opentelemetry-instrumentation-transformers/pyproject.toml:37
- Draft comment:
Upgraded the transformers dependency from ^4.51.3 to ^4.53.0. Confirm that this minor version upgrade is compatible with the instrumentation and does not introduce regressions. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is asking the PR author to confirm compatibility and check for regressions, which violates the rule against asking for confirmation or ensuring behavior is intended. It is related to a dependency change, which is also not allowed to be commented on unless it's a specific version issue that is recognized.
8. packages/sample-app/pyproject.toml:27
- Draft comment:
Multiple dependency updates: requests, tokenizers, transformers, and anthropic versions have been bumped, and security constraints for aiohttp and protobuf were added. Verify that these changes do not break the sample application and remain consistent with the instrumentation packages. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is asking the PR author to verify that the dependency changes do not break the application, which is against the rules. It also mentions ensuring consistency with instrumentation packages, which is another form of asking for verification. Therefore, this comment should be removed.
9. packages/traceloop-sdk/pyproject.toml:68
- Draft comment:
Updated traceloop-sdk dependencies: bumped aiohttp to ^3.12.14, added protobuf ^5.29.5, and updated anthropic to ^0.64.0 in test dependencies. Confirm these changes integrate well with all SDK plugins and do not introduce version conflicts. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
Workflow ID: wflow_BufCeESLPs34gENB
You can customize 
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
packages/opentelemetry-instrumentation-llamaindex/pyproject.toml (1)
31-33: Security constraints for aiohttp/protobuf — optional consolidationLooks good. To reduce maintenance overhead across many packages, consider a centralized constraints mechanism (mono-repo root constraints or a shared dependency group) so you don’t repeat these pins in every package.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (8)
packages/opentelemetry-instrumentation-anthropic/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-bedrock/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-langchain/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-llamaindex/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-openai/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-transformers/poetry.lockis excluded by!**/*.lockpackages/sample-app/poetry.lockis excluded by!**/*.lockpackages/traceloop-sdk/poetry.lockis excluded by!**/*.lock
📒 Files selected for processing (9)
packages/opentelemetry-instrumentation-anthropic/pyproject.toml(2 hunks)packages/opentelemetry-instrumentation-bedrock/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-langchain/pyproject.toml(2 hunks)packages/opentelemetry-instrumentation-llamaindex/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-openai/pyproject.toml(2 hunks)packages/opentelemetry-instrumentation-openai/tests/traces/test_chat.py(4 hunks)packages/opentelemetry-instrumentation-transformers/pyproject.toml(1 hunks)packages/sample-app/pyproject.toml(2 hunks)packages/traceloop-sdk/pyproject.toml(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.py
📄 CodeRabbit Inference Engine (CLAUDE.md)
**/*.py: Python code must conform to Flake8 linting rules
Do not hardcode API keys in source code; read them from environment variables or a secure vault
Files:
packages/opentelemetry-instrumentation-openai/tests/traces/test_chat.py
🔇 Additional comments (14)
packages/traceloop-sdk/pyproject.toml (1)
88-88: Anthropic test dep bump looks good; ensure tests still align with 0.64+ APIThe bump to ^0.64.0 is welcome given recent deprecations. Just ensure any fixture/helpers using tool-call structures or message schemas are updated accordingly.
Run package tests for traceloop-sdk locally (or CI) to confirm no breakages with AnthropIc 0.64+.
packages/opentelemetry-instrumentation-transformers/pyproject.toml (1)
37-37: Transformers bump to ^4.53.0: LGTMNo other deps here appear affected. 4.53.0 aligns with tokenizers >=0.19 and works on Python >=3.9.
If this instrumentation imports internal modules (rare, but some APIs move), please run this package’s test suite to verify no import path regressions against 4.53.x.
packages/opentelemetry-instrumentation-openai/pyproject.toml (2)
31-33: All pyproject.toml files consistently pin aiohttp and protobuf
Verified that every package (traceloop-sdk, sample-app, and all opentelemetry-instrumentation modules) uses aiohttp = "^3.12.14" and protobuf = "^5.29.5".Approving these security constraints.
47-47: Approve bump to requests 2.32.4 — no VCR/pytest-recording usage detectedAll tests in
packages/opentelemetry-instrumentation-openaiimport and callrequestsdirectly; there are noimport vcror pytest-recording cassettes in this package. The 2.32.4 security/bug-fix upgrade therefore has no impact on test-tooling compatibility.packages/sample-app/pyproject.toml (2)
27-39: Runtime bump set (requests/tokenizers/transformers/anthropic): looks coherent
- requests ^2.32.4, tokenizers ^0.21.0, transformers ^4.53.0, anthropic ^0.64.0 are mutually compatible for Python >=3.10.
- This matches the broader repo constraints and should reduce exposure to known CVEs.
If the sample app exercises Anthropic or HF models, please run a smoke test to verify:
- Anthropic 0.64+ tool/message schema usage
- Tokenizers 0.21 + Transformers 4.53 model loads (CPU-only) without extra compile steps.
60-62: Good: transitive security constraints added to the appExplicit aiohttp/protobuf pins in the app keep demo environments consistent with instrumentation expectations.
packages/opentelemetry-instrumentation-openai/tests/traces/test_chat.py (4)
391-399: LGTM: Using ChatCompletionMessageToolCall in pydantic-based tool_callsTyped construction improves schema validation and aligns with newer OpenAI SDKs. The guarded import for Function above is a good compatibility measure.
465-471: LGTM: Updated to ChatCompletionMessageToolCall for evented testConsistent with the new SDK type and the earlier import fallback for Function.
550-557: LGTM: Updated to ChatCompletionMessageToolCall in no-content variantKeeps parity across the suite. No issues spotted.
6-8: No fallback needed—openaiis pinned to ≥1.99.7 in this packageThe instrumentation’s own dependency (openai = "1.99.7") guarantees that
ChatCompletionMessageToolCallis available when running tests or users install the package. A backward‐compatible import guard isn’t required here.packages/opentelemetry-instrumentation-anthropic/pyproject.toml (2)
42-42: Verify AnthropIc client API exports after bump to >=0.64.0
Please confirm that the anthropic package (with thebedrockextras) in version >=0.64.0 continues to expose all of the client classes and constants used by our tests and fixtures. Specifically, ensure these are still available at the top level ofanthropic:
Anthropic(sync client)AsyncAnthropicAsyncAnthropicBedrockAI_PROMPT,HUMAN_PROMPTThese imports appear in:
- packages/opentelemetry-instrumentation-anthropic/tests/conftest.py
- packages/opentelemetry-instrumentation-anthropic/tests/test_bedrock_with_raw_response.py
- packages/opentelemetry-instrumentation-anthropic/tests/test_completion.py
If any symbol has moved or been renamed in the new release, please update the import paths or test code accordingly.
31-33: Verified: aiohttp@3.12.14 and protobuf@5.29.5 exist on PyPI
Security constraints look good. For maintainability and easier audits, consider centralizing shared constraints (e.g. in a top-level constraints file) instead of duplicating them in each package.• Location: packages/opentelemetry-instrumentation-anthropic/pyproject.toml (lines 31–33)
packages/opentelemetry-instrumentation-langchain/pyproject.toml (2)
31-33: Explicit transitive constraints (aiohttp/protobuf) — good hardeningThis is consistent with the rest of the PR and helps avoid vulnerable lower bounds being resolved.
55-55: Anthropic version compatibility confirmedlangchain-anthropic 0.3.13 requires
anthropic>=0.51.0,<1, and the bumpedanthropic = "^0.64.0"falls within that range. No changes needed.
| opentelemetry-semantic-conventions = ">=0.50b0" | ||
| opentelemetry-semantic-conventions-ai = "^0.4.12" | ||
| anthropic = ">=0.17.0" | ||
| anthropic = ">=0.64.0" |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Constrain AnthropIc upper bound (avoid surprise future breakages) and align style
An unbounded ">=0.64.0" risks breakage with future 0.x minors (Anthropic has introduced API shifts between 0.x minors). Other packages use ^0.64.0; align here or add an explicit upper bound.
Apply one of these (pick one to match your policy):
Option A — align with other packages:
-anthropic = ">=0.64.0"
+anthropic = "^0.64.0"Option B — guard against majors while allowing future 0.x:
-anthropic = ">=0.64.0"
+anthropic = ">=0.64.0,<1.0.0"To spot remaining inconsistencies across the repo:
🏁 Script executed:
#!/bin/bash
# Show all anthropic constraints and their contexts
rg -n -C1 -g '**/pyproject.toml' -e '^\s*anthropic\s*='Length of output: 1592
Align AnthropIc version constraint to caret for consistency
The packages/opentelemetry-instrumentation-bedrock/pyproject.toml currently allows any future 0.x release, which diverges from other packages pinning to ^0.64.0. Update it to match:
• File: packages/opentelemetry-instrumentation-bedrock/pyproject.toml
Line: 31
-opentelemetry-semantic-conventions-ai = "^0.4.12"
-anthropic = ">=0.64.0"
+opentelemetry-semantic-conventions-ai = "^0.4.12"
+anthropic = "^0.64.0"
tokenizers = ">=0.13.0"This change ensures uniform dependency style across the repo and guards against breaking 0.x releases.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| anthropic = ">=0.64.0" | |
| opentelemetry-semantic-conventions-ai = "^0.4.12" | |
| anthropic = "^0.64.0" | |
| tokenizers = ">=0.13.0" |
🤖 Prompt for AI Agents
packages/opentelemetry-instrumentation-bedrock/pyproject.toml around line 31:
the AnthropIc dependency is specified as `anthropic = ">=0.64.0"` which differs
from the repo's caret-style constraints; change it to use a caret range
`^0.64.0` so it matches other packages and prevents accidental incompatible 0.x
upgrades.
| aiohttp = "^3.12.14" | ||
| protobuf = "^5.29.5" |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Add rationale comment and validate cross-package compatibility for protobuf/aiohttp pins
Good call pinning vulnerable transitives. For traceability, mirror the explicit “Security constraints for transitive dependencies” comment you added elsewhere, and please double-check these pins don’t conflict with other packages (e.g., Google/OTLP stacks) in the monorepo.
Apply this small annotation:
posthog = ">3.0.2, <4"
-aiohttp = "^3.12.14"
-protobuf = "^5.29.5"
+# Security constraints for transitive dependencies
+aiohttp = "^3.12.14"
+protobuf = "^5.29.5"To verify alignment across the repo, run:
🏁 Script executed:
#!/bin/bash
# Show all protobuf/aiohttp constraints across the repo to detect drift or conflicts
rg -n -C1 -g '**/pyproject.toml' -e '^\s*(protobuf|aiohttp)\s*='Length of output: 2018
Add security constraints comment for transitive dependencies
We’ve confirmed that all other pyproject.toml files in the monorepo pin aiohttp = "^3.12.14" and protobuf = "^5.29.5" with a preceding
# Security constraints for transitive dependencies comment, and there are no version drifts or conflicts.
• File to update: packages/traceloop-sdk/pyproject.toml (around lines 73–74)
• Action: insert the comment above the pinned dependencies to match the rest of the repo
posthog = ">3.0.2, <4"
-aiohttp = "^3.12.14"
-protobuf = "^5.29.5"
+# Security constraints for transitive dependencies
+aiohttp = "^3.12.14"
+protobuf = "^5.29.5"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| aiohttp = "^3.12.14" | |
| protobuf = "^5.29.5" | |
| posthog = ">3.0.2, <4" | |
| # Security constraints for transitive dependencies | |
| aiohttp = "^3.12.14" | |
| protobuf = "^5.29.5" |
🤖 Prompt for AI Agents
In packages/traceloop-sdk/pyproject.toml around lines 73 to 74, add the missing
comment line "# Security constraints for transitive dependencies" immediately
above the existing pinned dependencies aiohttp = "^3.12.14" and protobuf =
"^5.29.5" so the file matches the rest of the monorepo; ensure the comment is on
its own line and preserved before those two dependency lines.
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed 370decf in 1 minute and 33 seconds. Click for details.
- Reviewed
299lines of code in23files - Skipped
24files when reviewing. - Skipped posting
2draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. packages/opentelemetry-instrumentation-alephalpha/pyproject.toml:42
- Draft comment:
vcrpy dependency bumped to ^7.0.0. Ensure no breaking API changes from v6 to v7 affect tests. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is about a dependency change and asks the author to ensure there are no breaking changes, which violates the rules. It doesn't provide a specific suggestion or point out a specific issue.
2. packages/sample-app/pyproject.toml:56
- Draft comment:
mcp dependency updated to ^1.13.0; verify that its API changes are compatible with the sample-app. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is asking the PR author to verify compatibility with the sample-app, which falls under the rule of not asking the author to ensure behavior is intended or tested. It does not provide a specific suggestion or point out a specific issue.
Workflow ID: wflow_mimdzQrn9BiEwGLI
You can customize
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
packages/opentelemetry-instrumentation-bedrock/pyproject.toml (1)
31-31: Align anthropic constraint style with other packagesOther packages use caret constraints for anthropic. Recommend switching for consistency and to avoid surprise future breakages from unbounded 0.x upgrades.
Apply:
-anthropic = ">=0.64.0" +anthropic = "^0.64.0"
🧹 Nitpick comments (2)
packages/opentelemetry-instrumentation-ollama/pyproject.toml (1)
35-42: Consider centralizing shared dev/test dependency versions to avoid driftGiven vcrpy is being bumped across many packages, consider a shared constraints file or top-level Poetry group in the monorepo to manage common test deps (pytest, pytest-asyncio, pytest-recording, vcrpy). This reduces duplication and drift in future security updates.
packages/opentelemetry-instrumentation-openai/pyproject.toml (1)
31-33: Confirm intent to promote transitive constraints to direct runtime depsAdding aiohttp and protobuf under main dependencies will be pulled by consumers even if not used directly by this package. If this is strictly for CVE mitigation, consider documenting the rationale, or (optionally) centralizing such constraints at a higher-level package to reduce surface area.
Would you like a short README note template explaining why these are direct deps for security constraints?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (24)
packages/opentelemetry-instrumentation-alephalpha/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-anthropic/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-bedrock/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-cohere/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-google-generativeai/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-groq/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-haystack/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-lancedb/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-langchain/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-llamaindex/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-marqo/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-mistralai/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-ollama/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-openai-agents/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-openai/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-pinecone/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-replicate/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-sagemaker/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-together/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-vertexai/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-watsonx/poetry.lockis excluded by!**/*.lockpackages/opentelemetry-instrumentation-weaviate/poetry.lockis excluded by!**/*.lockpackages/sample-app/poetry.lockis excluded by!**/*.lockpackages/traceloop-sdk/poetry.lockis excluded by!**/*.lock
📒 Files selected for processing (23)
packages/opentelemetry-instrumentation-alephalpha/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-anthropic/pyproject.toml(2 hunks)packages/opentelemetry-instrumentation-bedrock/pyproject.toml(2 hunks)packages/opentelemetry-instrumentation-cohere/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-google-generativeai/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-groq/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-haystack/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-lancedb/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-langchain/pyproject.toml(2 hunks)packages/opentelemetry-instrumentation-llamaindex/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-marqo/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-mistralai/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-ollama/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-openai-agents/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-openai/pyproject.toml(2 hunks)packages/opentelemetry-instrumentation-pinecone/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-replicate/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-sagemaker/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-together/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-vertexai/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-watsonx/pyproject.toml(1 hunks)packages/opentelemetry-instrumentation-weaviate/pyproject.toml(1 hunks)packages/sample-app/pyproject.toml(2 hunks)
✅ Files skipped from review due to trivial changes (4)
- packages/opentelemetry-instrumentation-vertexai/pyproject.toml
- packages/opentelemetry-instrumentation-alephalpha/pyproject.toml
- packages/opentelemetry-instrumentation-weaviate/pyproject.toml
- packages/opentelemetry-instrumentation-google-generativeai/pyproject.toml
🚧 Files skipped from review as they are similar to previous changes (4)
- packages/opentelemetry-instrumentation-llamaindex/pyproject.toml
- packages/sample-app/pyproject.toml
- packages/opentelemetry-instrumentation-anthropic/pyproject.toml
- packages/opentelemetry-instrumentation-langchain/pyproject.toml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: Test Packages (3.11)
- GitHub Check: Test Packages (3.10)
- GitHub Check: Test Packages (3.12)
- GitHub Check: Build Packages (3.11)
- GitHub Check: Lint
🔇 Additional comments (15)
packages/opentelemetry-instrumentation-ollama/pyproject.toml (1)
37-37: vcrpy 7.0.0 + pytest-recording compatibility verifiedAll tests using
@pytest.mark.vcrload with vcrpy 7.0.0 and pytest-recording resolves to 0.13.2 in the lockfile. There are no documented breaking changes in vcrpy 7.0.0 that affect pytest-recording or standard cassette formats.• Direct VCR usage is via
@pytest.mark.vcracross packages—no custom matcher hooks detected
•pyproject.tomlpins pytest-recording ^=0.13.1, lockfile upgraded it to 0.13.2
• No other vcrpy constraints remain below 7.0.0
• Web docs and changelogs show pytest-recording is compatible with vcrpy 7.x and no known breaking changesAction: Upgrade vcrpy, run the full test suite, and re-record any cassettes if mismatches surface.
packages/opentelemetry-instrumentation-mistralai/pyproject.toml (1)
38-38: Confirm pytest-recording compatibility with VCR.py 7.xpytest-recording 0.13.x is a thin wrapper around VCR.py and explicitly supports VCR.py 7.x. VCR.py 7.0.0 contains no cassette-format or matcher API changes that would break existing recordings. Your existing
@pytest.mark.vcrcassettes should continue to work unchanged.• Recommended: run the full test suite/CI in a clean environment with vcrpy 7 to catch any edge-case cassette errors (e.g. body key or decompression issues).
• If you do encounter failures, re-record the affected cassettes or pin to the previous VCR.py version.packages/opentelemetry-instrumentation-haystack/pyproject.toml (1)
42-42: Sanity-check vcrpy ^7.0.0 upgrade and pytest-recording compatibilityWe’ve confirmed that:
- pyproject.toml now pins vcrpy = "^7.0.0" alongside pytest-recording = "^0.13.1" (lock shows 0.13.2).
- vcrpy 7.0.0 drops Python 3.8 support and contains only minor bugfixes—no cassette-format or pytest-recording API breaks in v7 itself.
- vcrpy 6.x did include a cassette binary-format fix that may require re-recording cassettes created with earlier versions.
- vcrpy 5.x changed custom persister behavior (now must raise CassetteNotFoundError).
Before merging, please verify:
- Run the full test suite in record_mode=none/once; watch for UnhandledHTTPRequestError, CassetteNotFoundError or serializer errors.
- Re-record any failing cassettes (especially those originally recorded with vcrpy < 6.0.0).
- If you use custom persisters, ensure they raise CassetteNotFoundError as required by v5+.
- Smoke-test HTTP clients (httpx/urllib3/aiohttp) to catch any body/content serialization changes.
- Execute any concurrent tests to rule out multithreaded recording/playback races.
No code changes required in this PR—just the above sanity checks.
packages/opentelemetry-instrumentation-replicate/pyproject.toml (1)
37-37: vcrpy upgraded to ^7.0.0 – please validate pytest-recording compatibilityQuick checks:
- pyproject.toml now pins vcrpy = "^7.0.0" alongside pytest-recording = "^0.13.1", but poetry.lock has resolved pytest-recording to 0.13.2.
- All cassette usage is via
@pytest.mark.vcr(no directuse_cassettecalls).- vcrpy 7.0.0 includes important asyncio/httpx fixes, but pytest-recording’s docs only guarantee support up through vcrpy 5.x.
Next steps:
- Run your full test suite (including async/httpx flows) under CI with vcrpy 7.x.
- Watch for recording-time errors (e.g. “asyncio.run()…”); if you encounter failures, re-record affected cassettes.
- Optionally, bump pytest-recording to the latest 0.13.x patch (e.g. ^0.13.4) and re-verify.
packages/opentelemetry-instrumentation-groq/pyproject.toml (1)
38-38: vcrpy ^7.0.0 Compatibility ConfirmedAll tests in this package use pytest-recording (^0.13.1, locked at 0.13.2) with @pytest.mark.vcr, and there are no documented breaking changes to cassette formats or matchers in vcrpy 7.x. Existing cassettes remain valid, and no re-recording is required.
packages/opentelemetry-instrumentation-marqo/pyproject.toml (1)
41-41: All packages consistently bumped to vcrpy ^7.0.0 with matching pytest-recording constraints• Every
pyproject.tomlnow pins vcrpy ^7.0.0 alongside pytest-recording ^0.13.x (one package at ^0.13.2, all others at ^0.13.1)
• No directimport vcrusage found in code/tests—tests only use pytest-recording APIs
• To ensure cassette compatibility, run the full test suite and, if you hit serialization errors, re-record cassettes via:pytest --record-mode=rewritepackages/opentelemetry-instrumentation-sagemaker/pyproject.toml (1)
34-34: LGTM: Scoped test dependency bump aligns with PR objectivesvcrpy -> ^7.0.0 in test group is consistent with the repo-wide security refresh. No runtime impact expected.
packages/opentelemetry-instrumentation-cohere/pyproject.toml (1)
42-42: LGTM: Test-only vcrpy bump to ^7.0.0Matches the broader dependency hardening effort; low risk to runtime code.
packages/opentelemetry-instrumentation-together/pyproject.toml (1)
42-42: LGTM: vcrpy upgraded to ^7.0.0 in testsChange is consistent across packages and constrained to the test toolchain.
packages/opentelemetry-instrumentation-lancedb/pyproject.toml (1)
41-41: LGTM: Test dependency vcrpy bumped to ^7.0.0In line with the PR’s vulnerability resolution; no concerns from this file.
packages/opentelemetry-instrumentation-pinecone/pyproject.toml (1)
42-42: vcrpy 7 bump looks goodPython constraint here is >=3.9,<4, which aligns with vcrpy 7’s supported versions. No issues spotted.
packages/opentelemetry-instrumentation-watsonx/pyproject.toml (1)
29-29: vcrpy upgrade approvedUpgrade to ^7.0.0 is consistent with the repo-wide change and compatible with Python >=3.9.
packages/opentelemetry-instrumentation-openai/pyproject.toml (1)
42-47: Test deps bumps (vcrpy, requests) LGTMBoth upgrades are sensible and align with the PR objectives. No compatibility concerns flagged.
packages/opentelemetry-instrumentation-openai-agents/pyproject.toml (1)
39-39: vcrpy test dependency bump approvedMatches repo-wide update; no conflicts expected with current pytest/pytest-recording versions.
packages/opentelemetry-instrumentation-bedrock/pyproject.toml (1)
40-40: vcrpy 7 bump approvedConsistent with the rest of the repo; Python version compatibility is satisfied.
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed 6155b04 in 2 minutes and 29 seconds. Click for details.
- Reviewed
334lines of code in3files - Skipped
0files when reviewing. - Skipped posting
8draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. packages/opentelemetry-instrumentation-langchain/tests/test_llms.py:1067
- Draft comment:
Avoid using private attributes like _TRACEPARENT_HEADER_NAME in tests. Consider using a public constant or wrapper to access the traceparent header. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
2. packages/opentelemetry-instrumentation-langchain/tests/test_llms.py:195
- Draft comment:
Typo in comment: 'systm' should be 'system'. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
3. packages/opentelemetry-instrumentation-langchain/tests/test_llms.py:297
- Draft comment:
Hard-coded token counts (e.g. LLM_USAGE_PROMPT_TOKENS == 1497) may be brittle. Consider using an approximate check or a range. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
4. packages/opentelemetry-instrumentation-langchain/tests/test_llms.py:1706
- Draft comment:
The assert_message_in_logs helper uses strict equality for the log body. Consider checking that expected keys are a subset of the actual body to allow for extra metadata. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
5. packages/opentelemetry-instrumentation-langchain/tests/test_llms.py:568
- Draft comment:
In tests for OpenAI functions with events, the tool call 'id' is asserted as an empty string, while other tests (e.g. in agents) check for a 'call_' prefix. Verify consistency or document the difference. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
6. packages/opentelemetry-instrumentation-langchain/tests/test_llms.py:1340
- Draft comment:
Comparing span name lists using exact list equality can be brittle. Consider using set equality when order is not guaranteed. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
7. packages/opentelemetry-instrumentation-langchain/tests/test_langgraph.py:45
- Draft comment:
There appears to be extra trailing whitespace on this line. Consider removing unnecessary whitespace for consistency. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the trailing whitespace, this is an extremely minor style issue that doesn't affect functionality. The comment is in a test file, where style is generally less critical. The change would only remove 2 spaces and wouldn't meaningfully improve code quality or readability. The comment is factually accurate - there is trailing whitespace. And some teams do care about consistent whitespace even in test files. While technically correct, this level of nitpicking about whitespace in test files creates noise without adding value. The PR review should focus on more substantive issues. Delete this comment as it's too trivial and doesn't meaningfully improve code quality. Whitespace cleanup in test files is not worth the review overhead.
8. packages/opentelemetry-instrumentation-langchain/tests/test_langgraph.py:112
- Draft comment:
There's a trailing whitespace at the end of this line. Please remove the extra spaces to keep consistency. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% While the comment is technically correct about the trailing whitespace, our rules emphasize focusing on logic issues and avoiding trivial formatting comments. Trailing whitespace has no impact on functionality and would likely be handled by automated formatting tools. This seems like the kind of minor, unimportant issue we're supposed to avoid commenting on. The whitespace could be considered a consistency issue that might matter for code cleanliness. Some teams do care about trailing whitespace. While code cleanliness matters, this is exactly the kind of trivial issue that should be handled by automated tools rather than PR comments. It doesn't affect functionality and isn't worth the reviewer's or author's time. Delete this comment as it focuses on a trivial formatting issue that doesn't impact functionality and would be better handled by automated tools.
Workflow ID: wflow_doXI4FvUcRvNAGBC
You can customize
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed 0737ca7 in 1 minute and 27 seconds. Click for details.
- Reviewed
188lines of code in2files - Skipped
0files when reviewing. - Skipped posting
8draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. packages/opentelemetry-instrumentation-langchain/tests/test_agents.py:115
- Draft comment:
Good improvement: assistant_logs list comprehension was reformatted to multi-line for enhanced readability. No logic change. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
2. packages/opentelemetry-instrumentation-langchain/tests/test_agents.py:136
- Draft comment:
Choice_logs list comprehension is now multi-line; this enhances clarity in filtering logs with finish_reason 'tool_calls'. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
3. packages/opentelemetry-instrumentation-langchain/tests/test_agents.py:157
- Draft comment:
Final_choice_logs filtering was refactored into a multi-line list comprehension, which improves readability without affecting functionality. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
4. packages/opentelemetry-instrumentation-langchain/tests/test_agents.py:228
- Draft comment:
In the no-content tests, the multi-line formatting for assistant_logs, choice_logs, and final_choice_logs is consistently applied; this improves code style and readability. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
5. packages/opentelemetry-instrumentation-langchain/tests/test_langgraph.py:42
- Draft comment:
Reformatted the expected_spans.issubset assertion into a multi-line format. This change enhances clarity without altering logic. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
6. packages/opentelemetry-instrumentation-langchain/tests/test_langgraph.py:159
- Draft comment:
The mynode_spans and workflow_spans assertions in test_langgraph_double_invoke are now multi-line, which improves readability. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
7. packages/opentelemetry-instrumentation-langchain/tests/test_langgraph.py:205
- Draft comment:
Similarly, in test_langgraph_double_ainvoke, the multi-line formatting for span count assertions is a clear, stylistic improvement. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
8. packages/opentelemetry-instrumentation-langchain/tests/test_agents.py:129
- Draft comment:
Typographical suggestion: The string "OpenLLMetry" appears to be misspelled. Did you mean "OpenTelemetry"? - Reason this comment was not posted:
Comment was on unchanged code.
Workflow ID: wflow_VpvW7xwsZ1wvwBbh
You can customize
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (10)
packages/opentelemetry-instrumentation-langchain/tests/test_llms.py (3)
707-713: Avoid hard-coding Anthropic message IDs; assert shape/prefix instead.Asserting a fixed
response_metadata["id"]undermines the effort to ignore random IDs above. Prefer checking presence and a stable prefix likemsg_.Apply this diff to make the check robust:
- assert response_metadata["id"] == "msg_017fMG9SRDFTBhcD1ibtN1nK" + assert isinstance(response_metadata.get("id"), str) and response_metadata["id"].startswith("msg_")
701-705: Optional: relax exact content assertion to reduce cassette-coupling.Asserting the full assistant content ties the test to a specific cassette. If the intent is to validate instrumentation (not LLM text), consider asserting non-empty content or type-only.
Example alternatives:
- Assert non-empty:
assert isinstance(actual_output["content"], str) and actual_output["content"]- Or skip content equality and keep
type == "ai",tool_calls == [], etc.
721-726: Optional: tolerate absence ofinput_token_details.Some providers/versions omit
input_token_details. Use a safe default to avoid brittleness during re-recordings or version bumps.Apply this diff if you want a tolerant check:
- assert usage_metadata["input_token_details"] == {} + assert usage_metadata.get("input_token_details", {}) in ({}, None)packages/opentelemetry-instrumentation-langchain/tests/test_langgraph.py (4)
38-49: Robust span assertions: subset check is the right trade-off.Good adjustment to allow additional internal spans while ensuring core spans are present.
Tiny style nit: use a set comprehension for readability.
- actual_spans = set(span.name for span in spans) + actual_spans = {span.name for span in spans}
107-118: Async variant mirrors robustness — LGTM.Consistent use of subset checks across sync/async keeps tests resilient to instrumentation changes.
Same style nit:
- actual_spans = set(span.name for span in spans) + actual_spans = {span.name for span in spans}
148-169: Count checks per span name: clear and resilient.This verifies core spans occurred twice without being brittle to extra spans. Consider using Counter for clarity if desired.
Possible refactor:
- actual_span_names = [span.name for span in spans] - mynode_spans = [name for name in actual_span_names if name == "mynode.task"] - workflow_spans = [ - name for name in actual_span_names if name == "LangGraph.workflow" - ] - assert ( - len(mynode_spans) == 2 - ), f"Expected 2 mynode.task spans, got {len(mynode_spans)}" - assert ( - len(workflow_spans) == 2 - ), f"Expected 2 LangGraph.workflow spans, got {len(workflow_spans)}" + from collections import Counter + counts = Counter(span.name for span in spans) + assert counts["mynode.task"] == 2, f"Expected 2 mynode.task spans, got {counts['mynode.task']}" + assert counts["LangGraph.workflow"] == 2, f"Expected 2 LangGraph.workflow spans, got {counts['LangGraph.workflow']}"
194-214: Async double-invoke: same robust counting — small readability tweak optional.Mirrors the sync test well; a Counter-based approach can reduce boilerplate.
Same optional refactor as above using Counter.
packages/opentelemetry-instrumentation-langchain/tests/test_agents.py (3)
114-156: Use the EventAttributes constant instead of the raw "event.name" string.Keeps attribute key usage consistent and less error-prone across the codebase.
Apply this diff in the changed block:
- if log.log_record.attributes.get("event.name") == "gen_ai.assistant.message" + if log.log_record.attributes.get(EventAttributes.EVENT_NAME) == "gen_ai.assistant.message" @@ - if log.log_record.attributes.get("event.name") == "gen_ai.choice" + if log.log_record.attributes.get(EventAttributes.EVENT_NAME) == "gen_ai.choice"
158-172: Same: prefer EventAttributes over hard-coded "event.name".Keeps the filtering consistent with assert_message_in_logs below.
Apply this diff:
- if log.log_record.attributes.get("event.name") == "gen_ai.choice" + if log.log_record.attributes.get(EventAttributes.EVENT_NAME) == "gen_ai.choice"
227-281: Repeat: replace raw "event.name" with EventAttributes.EVENT_NAME for consistency.Prevents typos and aligns with the helper below that already uses the constant.
Apply this diff across the block:
- if log.log_record.attributes.get("event.name") == "gen_ai.assistant.message" + if log.log_record.attributes.get(EventAttributes.EVENT_NAME) == "gen_ai.assistant.message" @@ - if log.log_record.attributes.get("event.name") == "gen_ai.choice" + if log.log_record.attributes.get(EventAttributes.EVENT_NAME) == "gen_ai.choice" @@ - if log.log_record.attributes.get("event.name") == "gen_ai.choice" + if log.log_record.attributes.get(EventAttributes.EVENT_NAME) == "gen_ai.choice"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
packages/opentelemetry-instrumentation-langchain/tests/test_agents.py(2 hunks)packages/opentelemetry-instrumentation-langchain/tests/test_langgraph.py(4 hunks)packages/opentelemetry-instrumentation-langchain/tests/test_llms.py(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.py
📄 CodeRabbit Inference Engine (CLAUDE.md)
**/*.py: Python code must conform to Flake8 linting rules
Do not hardcode API keys in source code; read them from environment variables or a secure vault
Files:
packages/opentelemetry-instrumentation-langchain/tests/test_llms.pypackages/opentelemetry-instrumentation-langchain/tests/test_agents.pypackages/opentelemetry-instrumentation-langchain/tests/test_langgraph.py
🧬 Code Graph Analysis (1)
packages/opentelemetry-instrumentation-langchain/tests/test_langgraph.py (1)
packages/traceloop-sdk/traceloop/sdk/utils/in_memory_span_exporter.py (1)
get_finished_spans(40-43)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: Test Packages (3.11)
- GitHub Check: Test Packages (3.10)
- GitHub Check: Test Packages (3.12)
- GitHub Check: Build Packages (3.11)
- GitHub Check: Lint
🔇 Additional comments (1)
packages/opentelemetry-instrumentation-langchain/tests/test_llms.py (1)
698-705: Good: filter out non-deterministicidfromkwargs.This reduces brittleness and aligns with the goal of making the test resilient to random IDs.
Important
Updated dependencies across multiple packages to resolve vulnerabilities and improve compatibility, with corresponding test updates.
vcrpyto^7.0.0in multiplepyproject.tomlfiles.anthropicto^0.64.0inopentelemetry-instrumentation-anthropicandopentelemetry-instrumentation-bedrock.transformersto^4.53.0andtokenizersto^0.21.0insample-app.aiohttp^3.12.14andprotobuf^5.29.5as security constraints in several packages.test_chat.pyto use the renamedChatCompletionMessageToolCalltype.test_agents.pyandtest_langgraph.pyto validate logs and spans with updated logic.requeststo^2.32.4andmcpto^1.13.0insample-app.This description was created by
for 0737ca7. You can customize this summary. It will automatically update as commits are pushed.
Summary by CodeRabbit