GitHub user weiqingy added a comment to the discussion: [Discussion][Observability 1/2] Recording Agent Traces in the Event Log
Thanks, this resolves what I raised. Execution counting, boundary safety, and the trace-enabled default all read settled to me. **Run identity.** You're right on the general case. A replayed record with no restored Action state is genuinely a second execution, so a fresh run id describes what happened. The one case I land on is replay combined with durable-execution reuse, since `ActionState` survives a restart in an external store. The replayed input gets a fresh run id and its Action is recorded `reused`, while every nested LLM and Tool execution for that same work was already flushed under the previous run id. Your point about persisted output Events keeping their original IDs does give a way to bridge the two, which I had underrated, though it goes through the business-event stream rather than the trace itself. So my question is narrower than run-id stability: would it be worth the `reused` execution carrying the identity of what it reuses, either the original `execution_id` or `input_run_id`? Today it carries only `status`. That keeps your resume-versus-replay rule as is, and for an OTel exporter it is the difference between two disconnected traces and a link. Since the implementation is up in #924, I have left my remaining comments there and will keep further detail on the PR. GitHub link: https://github.com/apache/flink-agents/discussions/900#discussioncomment-17792817 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
