GitHub user joeyutong added a comment to the discussion: [Discussion][Observability 1/2] Recording Agent Traces in the Event Log
Thanks for raising these questions. They help clarify several boundaries that were not explicit enough in the proposal. **Run identity.** At present, `input_run_id` identifies one runtime processing instance. It is preserved when an existing `ActionTask` is restored from Flink state, but a source-replayed input receives a new ID, so the current behavior follows Flink's resume-versus-replay boundary and is partly checkpoint-dependent. After reviewing #841, I have not yet identified a Trace requirement that necessarily requires replay stability. Do you have a concrete case where `input_run_id` must remain stable across source replay? **Execution counting.** Good catch. The current wording and prototype are not fully aligned: the LLM lifecycle currently wraps the retry loop, while each Parser invocation is recorded separately. I think the cleaner contract is one execution per framework-observed invocation. Each retry that calls the model again would create a new LLM execution, and each parse attempt would remain a separate Parser execution; provider-internal retries would remain out of scope. A separate retry Event or attempt count is unnecessary because the repeated executions are already visible under the same Action. **Boundary safety.** The prototype intentionally keeps built-in Execution Event reporting outside `EventRouter`, so enabling observability does not implicitly trigger Actions, notify user listeners, or otherwise change workflow behavior. However, making “Execution Events never route” a permanent restriction may be unnecessarily strong. I would define and test the narrower contract that built-in lifecycle reporting does not automatically submit these Events to `EventRouter`, while leaving room for an explicit integration in the future. **Operational cost.** A coarse-grained Trace recording option seems appropriate for the initial implementation. I propose an `event-log.trace.enabled` option that controls whether trace context and Execution Events are persisted to the Event Log, while in-process lifecycle observation remains active for metrics. I would default it to disabled to avoid increasing Event Log volume for existing jobs. Sampling can be considered later, but it should be decided per run rather than per Event so that recorded Traces remain complete. **Durable replay.** The current recording should not make a replayed output look freshly produced. When a completed `ActionState` is reused, the runtime records the current Action execution with `status=reused` rather than `started` or `finished`, and the persisted output Events are associated with that same reused execution while retaining their original Event IDs. A Trace consumer can therefore represent them as outputs replayed from durable state. GitHub link: https://github.com/apache/flink-agents/discussions/900#discussioncomment-17697189 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
