feat(milvus): Add error.type attribute from OpenTelemetry Semantic Conventions

[divyapathak24]

Fixes #3008

• 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

Adds error.type attribute to Milvus spans for better error tracking, with tests for invalid vector search.

• Behavior:
  • Adds error.type attribute to spans in wrapper.py using ERROR_TYPE from OpenTelemetry Semantic Conventions.
  • Maps error codes to error types with code_to_error_type dictionary.
  • Updates _wrap() to set error.type on exceptions.
• Testing:
  • Adds test_error.py to test error.type attribute setting during a failed search operation.
  • Verifies error.type is set to internal_error for invalid vector search.

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

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to d112361 in 1 minute and 30 seconds. Click for details.

• Reviewed 178 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 1 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-milvus/tests/test_error.py:87

• Draft comment:
  The test verifies that error.type is set to 'internal_error', which works if the exception has a matching code. Consider adding tests for exceptions both with and without a 'code' attribute to fully validate the fallback behavior.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment suggests testing error handling more thoroughly, which is generally good practice. However, without seeing the actual error handling code being tested or understanding what the 'code' attribute refers to, we can't be certain this suggestion is relevant or actionable. The test file is new, so we're seeing all changes. I don't have visibility into the actual error handling code being tested, so I can't be sure if testing for a 'code' attribute is even applicable. The comment might be making assumptions about implementation details we can't verify. While better error test coverage could be valuable, without seeing the implementation code, we can't be confident this specific suggestion is relevant or actionable. The comment should be deleted as it makes assumptions about implementation details we can't verify from the test file alone, and thus may not be actionable or relevant.

Workflow ID: wflow_L40sXdEABayPmKJG

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

[divyapathak24]

@nirga could you take a look at this PR ?

[nirga]

Left a small comment

[nirga]

you should also set the span status as error

[divyapathak24]

@nirga I have raised the exception at line 85 in wrapper.py, which automatically sets the span status to "error"—as shown in the attached screenshot as well.

I have also added a test to verify that the span status is correctly set to "error" line 88 in test_error.py