GitHub user Zhuoxi2000 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.
Answering from the exporter side, since this is the concrete use case
@joeyutong asked about earlier.
Yes, I think the exporter needs both identifiers.
The OTel primitive here would be a Span Link, since the reused work is causally
related but should not be reparented into the new trace. A link points to a
full `SpanContext`, so it needs both a trace id and a span id. In the mapping I
sketched in #929, that means deriving the trace id from `input_run_id` and the
span id from `execution_id`.
So something like `reused_from: { input_run_id, execution_id }` feels like the
minimal shape needed to create a valid link. It only needs to be present when
`status` is `reused`.
Without this, a replayed run may show an Action span with no LLM / Tool
children and no obvious reason why. With it, a generic OTLP backend can link
the reused span back to the original execution, without double-counting or
silently dropping attribution.
The persisted output Events can bridge this for custom backends that ingest and
join the business-event stream, but that relationship would not be visible in a
generic trace UI.
Happy to fold whichever shape you settle on into the exporter design in #929.
GitHub link:
https://github.com/apache/flink-agents/discussions/900#discussioncomment-17865331
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
