feat: add Pinecone Inference and Assistant instrumentation support

[Mantissagithub]

Description

This PR implements instrumentation support for the new Pinecone Inference and Assistant APIs as requested in issue #1618.

Changes Made

• Add instrumentation for Pinecone Inference embedding and reranking operations
• Add instrumentation for Pinecone Assistant chat, creation, and file operations
• Include comprehensive span attributes matching OpenAI instrumentation patterns
• Add token usage tracking and conversation logging
• Update pinecone-client dependency to ^6.0.0 for new API support
• Add comprehensive tests for both inference and assistant features

Resolves #1618

Checklist

• I have added tests that cover my changes.
• If adding a new instrumentation or changing an existing one, I've added screenshots from some observability platform showing the change.
• PR name follows conventional commits format: feat(instrumentation): ... or fix(instrumentation): ....
• (If applicable) I have updated the documentation accordingly.

---

Important

Add instrumentation for Pinecone Inference and Assistant APIs, update dependencies, and add tests.

• Instrumentation:
  • Add support for Pinecone Inference (embed, rerank) and Assistant (create_assistant, chat, upload_file) methods in __init__.py.
  • Implement set_inference_input_attributes and set_inference_response_attributes in inference_handlers.py.
  • Implement set_assistant_input_attributes and set_assistant_response_attributes in assistant_handlers.py.
• Dependencies:
  • Update pinecone-client dependency to ^6.0.0 in pyproject.toml.
• Testing:
  • Add test_assistant.py for testing Assistant API instrumentation.
  • Add test_inference.py for testing Inference API instrumentation.

^{This description was created by for d735dd5. You can customize this summary. It will automatically update as commits are pushed.}

[CLAassistant]

All committers have signed the CLA.

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to d735dd5 in 2 minutes and 5 seconds. Click for details.

• Reviewed 343 lines of code in 6 files
• Skipped 0 files when reviewing.
• Skipped posting 8 draft 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-pinecone/opentelemetry/instrumentation/pinecone/inference_handlers.py:14

• Draft comment:
  Typo in comment: 'emebedding' should be 'embedding'.
• 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 typo exists, comments about typos in comments are generally not valuable enough to warrant a PR comment. The typo doesn't affect functionality, readability is only minimally impacted, and fixing it is not an important code change. This falls under the "Do NOT make comments that are obvious or unimportant" rule. The typo could theoretically make the code slightly harder to search for if someone was searching for "embedding". Also, maintaining professional quality includes fixing typos. While those points have merit, the impact is extremely minimal and this type of minor comment creates noise in the PR review process. The benefit doesn't justify the overhead of a PR comment. Delete this comment as it points out an unimportant typo in a comment that doesn't meaningfully impact code quality or understanding.

2. packages/opentelemetry-instrumentation-pinecone/opentelemetry/instrumentation/pinecone/inference_handlers.py:27

• Draft comment:
  Typo in comment: 're-raking' should be 'reranking'.
• 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 this is technically correct, it's an extremely minor typo in a comment that doesn't affect code functionality. The meaning is still clear from context. Comments about pure typos in comments, unless they significantly impact understanding, generally don't meet the bar of "clearly requiring a code change". The typo could potentially cause confusion for future developers reading the code. It's a quick fix that would improve code quality. The typo is so minor and the intended meaning so obvious from context (method name "rerank", other comments using "reranking") that it doesn't justify a PR comment. Delete this comment as it points out an extremely minor issue that doesn't meet the bar of "clearly requiring a code change".

3. packages/opentelemetry-instrumentation-pinecone/opentelemetry/instrumentation/pinecone/__init__.py:187

• Draft comment:
  Consider caching the extracted method name (e.g. using a local variable) to avoid repeated calls to method.split('.') in the input and response handling blocks.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

4. packages/opentelemetry-instrumentation-pinecone/opentelemetry/instrumentation/pinecone/__init__.py:188

• Draft comment:
  Minor nit: Consider adding a space after the '#' in the inline comment on this line (i.e., change #extract embed or re-rank to # extract embed or re-rank) to improve readability and conform to Python style guidelines.
• 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 according to PEP 8, it's an extremely minor style issue. Our rules state we should only keep comments that require clear code changes, and to not make comments that are obvious or unimportant. Style nits like this are very minor and could be handled by automated formatters. The comment is technically correct and points out a real PEP 8 violation. Having consistent code style does improve readability. While correct, this is too minor of an issue to warrant a PR comment. It doesn't affect functionality and could be handled by automated tools. Delete this comment as it's too minor of a style issue to warrant a PR comment, according to our rules about not making obvious or unimportant comments.

5. packages/opentelemetry-instrumentation-pinecone/opentelemetry/instrumentation/pinecone/inference_handlers.py:14

• Draft comment:
  Typo in comment: 'emebedding specific attributes'. Consider changing 'emebedding' to 'embedding'.
• 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 typo, comments about typos in comments are generally not important enough to warrant a PR comment. The typo doesn't affect functionality, readability is barely impacted, and fixing it would create unnecessary churn. This falls under the "Do NOT make comments that are obvious or unimportant" rule. The typo could be seen as reducing code quality and professionalism. It might be worth fixing for maintainability and documentation standards. While professional code is important, this is an extremely minor issue that doesn't impact functionality or significantly impact readability. The cost of the review comment outweighs the benefit of the fix. Delete this comment as it points out an unimportant typo in a comment that doesn't meaningfully impact code quality or understanding.

6. packages/opentelemetry-instrumentation-pinecone/opentelemetry/instrumentation/pinecone/inference_handlers.py:27

• Draft comment:
  Typo in comment: 're-raking specific attributes'. Consider changing 're-raking' to 're-ranking'.
• 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 typo exists, comments are documentation and should be correct. However, the rules state not to make purely informative comments and to only comment if there's clearly a code change required. This is a very minor documentation issue that doesn't affect functionality. The typo could theoretically confuse future readers about the purpose of this code section. Also, maintaining consistent terminology in comments is important for code maintainability. While consistency is good, this is an extremely minor documentation issue. The meaning is still clear from context, and the rules explicitly state not to make purely informative comments. The comment should be deleted as it's purely informative and doesn't require a functional code change.

7. packages/opentelemetry-instrumentation-pinecone/tests/test_assistant.py:18

• Draft comment:
  The model name 'gpt-4o' appears here. Is this a typographical error? Consider verifying if it should be 'gpt-4'.
• 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% Since this is a test file, the exact model name used doesn't matter as long as it's consistent. The test explicitly asserts the same model name, showing it's intentional. Even if "gpt-4o" isn't a real model name, it's perfectly fine for testing purposes. The comment is questioning something that appears to be deliberately set up this way. Maybe this is actually catching a real typo that was accidentally copied into the assertion as well? In test files, using fake/mock values is common practice. Whether this is a real model name or not doesn't impact the test's validity. Delete the comment. The model name appears to be intentionally chosen for testing, and the test consistently uses this name in both the request and assertion.

8. packages/opentelemetry-instrumentation-pinecone/tests/test_assistant.py:25

• Draft comment:
  The model name 'gpt-4o' appears in the assertion as well. Please confirm whether it needs to be 'gpt-4'.
• 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% The test is checking that the model name in the span attributes matches exactly what was passed to the chat() function. Whether 'gpt-4o' is a valid model name or not is irrelevant - the test is about correct attribute propagation. The comment is asking for confirmation, which violates our rules. It's also speculative since it's not definitively stating there's an issue. Maybe there's a typo in the model name that could cause issues in production if not caught during testing. The purpose of this test is to verify telemetry attribute propagation, not to validate model names. If 'gpt-4o' is invalid, that would be caught by actual API calls or other validation tests. Delete the comment. It's asking for confirmation rather than pointing out a definite issue, and the model name accuracy is not relevant to this telemetry test.

Workflow ID: wflow_9SfZSLgHcF4fz19L

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}