GitHub user weiqingy added a comment to the discussion: [Discussion][Observability 1/2] Recording Agent Traces in the Event Log
Thanks for the detailed write-up. The split between Business Events and Execution Events reads right to me. A few questions on the recording contract before implementation, mostly around run identity, execution lifecycle, and replay boundaries. **Run identity.** The proposal says the runtime creates or restores a run context, but doesn't define how `input_run_id` is derived. This reinforces the replay-stability concern already raised on the thread, with a second failure mode on the Python side: in #841 the worry was that `inputEvent.id` isn't stable enough. Java may mint a fresh UUID when wrapping an input on replay, while Python's content-derived IDs can collapse distinct inputs with identical payloads. Would it make sense to derive `input_run_id` from stable runtime coordinates, such as job/agent identity + business key + per-key input sequence, or another explicitly replay-aware source? **Execution counting.** §4.2 and §6 seem to point in slightly different directions: §4.2 says invoking the same entity twice creates two distinct executions, while §6 says retry attempts don't count as separate LLM executions. In the structured-output path, the model call and parse may be retried together, so a call that succeeds after parse retries could read as one LLM execution but several Parser executions under the same Action. Would it be worth stating the retry-collapsing rule once at the execution level, so Parser and LLM counting are consistent, for example one execution per logical call carrying an attempt count? **Boundary safety.** Since Execution Events reuse the existing `Event` structure, and the `_` prefix today marks types that route normally (`_input_event`, `_chat_request_event`, etc.), would it be worth making "Execution Events never route" an explicit invariant backed by a focused test? That would keep a future call path from accidentally treating an `_execution_*` record as a routable business Event. **Operational cost.** Explicit Action/LLM/Parser/Tool lifecycle records can multiply Event Log volume noticeably for tool-heavy agents. Would the first implementation include a recording switch or sampling option, or at least clear guidance on when to expect log growth and whether recording is on by default? **Durable replay.** For `ActionStateStore` replay, a reused Action records a `reused` Execution Event, but its persisted output Events continue through the current run without the original `ExecutionTraceContext`. That's honestly noted as a limitation. Could it make trace reconstruction misleading in durable mode, where a replayed output looks freshly produced? Would it be feasible to store the original trace context with the completed Action, or, failing that, mark replayed output Events as "replayed from prior execution" so consumers don't infer a fresh causal production? GitHub link: https://github.com/apache/flink-agents/discussions/900#discussioncomment-17692923 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
