fix(tracer): add gen_ai.operation.name event type detection (Priority 4.5)#291
Conversation
… 4.5) Add detection of gen_ai.operation.name attribute for event type classification. This fixes incorrect event_type for strands-agents spans where invoke_agent and create_agent were defaulting to 'tool' instead of 'chain'. Priority 4.5 (before pattern matching fallback): - chat, text_completion, generate_content -> model - invoke_agent, create_agent -> chain - execute_tool -> tool This works alongside the backend fix in hive-kube ingestion service to ensure correct event types for AWS Strands and other GenAI semantic convention instrumentors. Co-Authored-By: unknown <>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
|
Claude finished @devin-ai-integration[bot]'s task in 1m 39s —— View job Review complete
Summary: The change is well-scoped and correctly placed at Priority 4.5. Left feedback on three items:
Also left inline nits on dict allocation per call and logging style inconsistency (non-blocking). |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| op_name = attributes.get("gen_ai.operation.name") | ||
| if op_name: | ||
| op_name_str = str(op_name) | ||
| OPERATION_NAME_TO_EVENT_TYPE = { |
There was a problem hiding this comment.
Nit: dict recreated on every call. This dict is allocated on each invocation of _detect_event_type. The existing OPENINFERENCE_TO_HONEYHIVE at Priority 4 has the same pattern so this is at least consistent, but both should ideally be hoisted to module-level or class-level constants.
Not blocking, but worth a follow-up cleanup for both mapping dicts together.
| OPERATION_NAME_TO_EVENT_TYPE = { | |
| _OPERATION_NAME_TO_EVENT_TYPE = { |
There was a problem hiding this comment.
Acknowledged — this is consistent with the existing OPENINFERENCE_TO_HONEYHIVE dict pattern at Priority 4. Will defer hoisting both to module-level constants to a follow-up cleanup.
| self._safe_log( | ||
| "debug", | ||
| "✅ Event type from gen_ai.operation.name: %s (%s)", | ||
| event_type, | ||
| op_name_str, | ||
| ) |
There was a problem hiding this comment.
Nit: Logging style inconsistency. This block uses %s lazy formatting (good practice for logging), but the Priority 4 block above (lines 1052–1054) uses f-strings inside _safe_log. The %s style here is actually the better approach — consider aligning Priority 4 to match in a follow-up.
There was a problem hiding this comment.
Good catch — %s lazy formatting is intentional here and is the better approach. Agree that Priority 4's f-strings should be aligned in a follow-up.
Review SummaryThe change is well-scoped and the mapping logic is correct. Priority placement between OpenInference (4) and dynamic pattern matching (5) is the right slot. A few items to address: What looks good:
Issues to address:
DocumentationNo public API changes — no doc updates needed. The PR description's mapping table is sufficient for internal reference. |
|
📚 Documentation preview built — Download artifact Review instructions & validation statusHow to Review
Validation Status
|
- Update _detect_event_type docstring to reflect all 6 priority levels - Add 'embeddings' -> 'tool' mapping (standard GenAI semantic convention) Co-Authored-By: unknown <>
|
Addressed items 1 and 3 in 9bc83c6:
|
|
📚 Documentation preview built — Download artifact Review instructions & validation statusHow to Review
Validation Status
|
Summary
Adds a new event type detection priority (4.5) in
HoneyHiveSpanProcessor._detect_event_type()that checks thegen_ai.operation.namespan attribute before falling back to dynamic pattern matching (Priority 5).This fixes incorrect
event_typeclassification for strands-agents spans (and potentially other GenAI semantic convention instrumentors like PydanticAI v3+). Without this fix, spans likeinvoke_agentandcreate_agentfall through to pattern matching and get classified astoolinstead ofchain.Mapping added:
gen_ai.operation.nameevent_typechat,text_completion,generate_contentmodelinvoke_agent,create_agentchainexecute_tooltoolembeddingstoolCompanion backend fix: honeyhiveai/hive-kube#2516 (same priority logic in ingestion service's
event_type.go).Updates since last revision
_detect_event_type()docstring now documents all 6 priority levels including Priority 4.5 and the full gen_ai.operation.name mapping table.embeddingsmapping added: Mapped totool, consistent with OpenInferenceEMBEDDING → tool. Prevents future unmapped operation name fall-through for standard GenAI embeddings operations.Review & Testing Checklist for Human
gen_ai.operation.name, not just Strands. Verify that other frameworks using this attribute (e.g., Traceloop, OpenInference) either don't set it or would benefit from the same mapping.gen_ai.operation.namevalues exist in the wild that should be mapped (e.g.,rerank). Unmapped values silently fall through to Priority 5 pattern matching, which is safe but may produce unexpected results.invoke_agent→chainandchat→model. The change was validated via the strands-agents integration example, but there's no automated test guarding against regression.Recommended test plan: Run the strands-agents integration example, retrieve the session from the API, and verify:
chatspans haveevent_type: "model"(SDK-side fix, works now)invoke_agentspans getevent_type: "chain"after the companion backend PR (honeyhiveai/hive-kube#2516) is deployedNotes
OPERATION_NAME_TO_EVENT_TYPEdict is defined inside the method (recreated per call). Minor perf concern; could be hoisted to a class/module constant.