GitHub user weiqingy added a comment to the discussion: [Discuss][Observability] OpenTelemetry GenAI export for Agent Traces (follow-up to #900)
Thanks for working through these. I think this narrows the remaining questions considerably. Assuming each converter invocation receives a fixed, complete set of already-collected files, the batch shape seems to resolve the ordering and timeout questions: the converter can group records by `inputRunId`, sort them, and use end-of-input rather than a timeout to determine that no more records are coming. Incomplete executions may still be present, though. `EventLogWriter` calls append and flush for each record, but treats failures as best-effort and does not retry them. A crash can also leave a start record in the collected files without a terminal record. A restored Action execution keeps its `executionId` and `inputRunId`, since both are checkpointed with the `ActionTask`. By contrast, the state pairing nested LLM, Parser, and Tool starts with their terminal reports is transient, so recovery can produce new child executions under the same run. How would we like those incomplete executions to appear in the exported trace? Would omitting them hide useful evidence of failed work, while synthesizing an end timestamp risk implying a duration we did not observe? Could emitting them as errors with an explicit "incomplete/synthetic close" marker preserve that distinction, or would a diagnostic-only record be clearer? Could [`trace_tree.py`](https://github.com/apache/flink-agents/blob/1c55683deb5c7e8d44997851403e75b5c0fbdb57/python/flink_agents/cli/trace_tree.py) provide a useful precedent for input validation and diagnostics? It reports conditions such as `MISSING_PARENT` for business-event lineage and `MALFORMED_RECORD` for invalid input. Although it intentionally ignores execution lifecycle records and therefore does not answer the incomplete-span policy itself, might its warning model be reusable? It also discovers only `events-*.log`, which is the `FileEventLogger` naming contract rather than the default SLF4J output. Would it help for Phase 1 to state whether the converter consumes specifically `FileEventLogger` JSONL files, including how a complete multi-subtask file set is identified, or normalized records collected from any Event Log sink? I also wonder whether the Parser mapping could be explicit. The run/root/parent fields establish its topology, but the converter still needs to decide its span name, `gen_ai.operation.name`, and OTel span kind. Since #924 records PARSER as a first-class execution type, would defining one stable mapping here make traces more consistent across converter versions? The OTel GenAI convention permits a custom `gen_ai.operation.name` when none of its well-known values applies, and OpenLLMetry uses that mechanism for names such as `execute_task` and `llm_request`. OpenInference's `CHAIN`, `GUARDRAIL`, and `EVALUATOR` values belong to the separate `openinference.span.kind` classification. Since Phoenix and Langfuse recognize that convention, would it be worth deciding whether Phase 1 emits only OTel GenAI attributes or also an OpenInference classification for AI-aware rendering? Separately, for the OTel span kind, would `SpanKind.INTERNAL` fit Parser, and perhaps Action, as in-process work, while preserving `CLIENT` for spans that directly represent remote calls? GitHub link: https://github.com/apache/flink-agents/discussions/929#discussioncomment-17956163 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
