GitHub user rosemarYuan added a comment to the discussion: [Discussion] Agent observability: tracing & evaluation beyond metrics + event log
Thanks for raising these questions. They help clarify several boundaries that were not explicit enough in the proposal. **Field placement.** I would keep `upstream_event_id` and `upstream_action_name` on the Event. I consider them framework-managed, intrinsic metadata of an Event occurrence, similar to its `id` and `type`, rather than optional execution-tracing context. This keeps the Event–Action–Event relationship available in the standard Event Log even when the richer tracing in #900 is disabled. #900 serves a different purpose: its `ExecutionTraceContext` describes a concrete execution, including run identity, invocation hierarchy, lifecycle, and status. Event lineage remains the source of truth for the Event’s immediate causal origin, while #900 provides finer-grained, execution-based relationships and context. **Python identity.** I agree that the current content-derived Python Event ID creates both problems. I plan to align Python with Java by generating a new UUID for each Event occurrence. The ID will remain unchanged after the Event is created, so attaching framework-managed lineage will not affect it. Events with identical payloads will also receive different IDs and remain separate nodes during reconstruction. **Ordering and replay.** We considered adding `emitIndex`, but sibling Events share a causal parent rather than a causal relationship with one another. The minimal tree therefore does not guarantee their order. Preserving it across Python async execution and replay would add complexity without a clear current use case. Similarly, distinguishing repeated invocations, retries, and reused results requires execution identity. Those semantics belong to #900. For partial logs, the reader can report a missing parent, but neither a run ID nor an ordering field can recover records that are no longer available. **Proposed boundary.** The two-field proposal provides an independently usable Event–Action–Event causal tree. #900 provides the complete execution trace, including run and invocation identity, execution hierarchy, lifecycle, reuse, and failures. Does this distinction address your concerns about field placement, Python identity, replay, and ordering? GitHub link: https://github.com/apache/flink-agents/discussions/710#discussioncomment-17711669 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
