GitHub user weiqingy added a comment to the discussion: [Discussion] Agent observability: tracing & evaluation beyond metrics + event log
Thanks for writing this up — I like the backward-edge direction. Because the framework already knows the triggering Event and the emitting Action when an Action emits an Event, recording `upstream_event_id` + `upstream_action_name` can reconstruct the Event → Action → Event tree without later-update writes. The two-field first phase reads sensible to me. A few questions, mostly around field placement and Java/Python reconstruction behavior. **Where the fields live.** One question is whether `Event` itself is the right carrier. Even outside `attributes`, `Event` is still the public business-event object: it flows through routing, listeners, action state, and cross-language serde. #900 moves trace data toward a separate `ExecutionTraceContext` / log-record envelope, so putting lineage on `Event` risks creating a second metadata location that #900 later has to reconcile. There is a real pull the other way, though: if the fields ride on the persisted Event, they survive `ActionStateStore` replay for free. A reused Action re-emits its persisted output Events verbatim, so the causal edge comes back intact, whereas #900 §8 notes that separate trace context is not stored with completed Actions and replayed outputs cannot link back to the original execution. So this feels like a genuine trade-off rather than a simple "Event is the wrong home" question. Where do you see it landing: lineage on the log record/context like #900, or on the Event to preserve the replay property? **Python identity.** Two Python-specific details seem worth pinning down. First, Python `Event.id` is content-derived from event content excluding `id`, so adding framework-managed fields to the Event model could change the id unless those fields are explicitly excluded. That invariant seems important if the fields stay on Event. Second, because Python ids are already content-derived, two runs triggered by the same input payload can get the same root id. With rootless reconstruction — index by `event_id`, empty `upstream_event_id` means root — those distinct runs can collapse into one tree, while Java's per-occurrence UUIDs keep them apart. Does that make "no run id" more than a locating limitation for Python? How should same-payload roots stay distinct? **Ordering and partial logs.** With only `upstream_event_id` + `upstream_action_name`, multiple sibling Events from one invocation, retries/replay, or repeated invocations of the same Action from the same source Event may be hard to order or tell apart. Partial logs also cannot recover a root. Would a minimal invocation id or emit index earn its place in this phase, or should those cases be explicitly deferred to #900? GitHub link: https://github.com/apache/flink-agents/discussions/710#discussioncomment-17694197 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
