Agents SDK: startActivity spans should finish when the activity has been sent to the server

[tconley1428]

What was changed

Instead of tracking the startActivity span across the duration of the activity, leave that up to the workflow. StartActivity is finished upon scheduling

Why?

Checklist

1. Closes [Bug] Langfuse Tracing Not Working with Temporal OpenAI Agents Plugin #1136

2. How was this tested:

3. Any docs updates needed?

[cretz]

I see this code changed here and in a few places. IIRC, it was intentional that we did set_header_from_context inside the with custom_span so the header has that current span serialized (and therefore spans that occur inside workflow will have this as a parent).

[tconley1428]

It was, but I think it wasn't actually correct to do. Since the signal span would more or less immediately end, I think it is misleading to parent the child workflow execution to the signal span. Rather, the child workflow is parented to the parent workflow's span (or whatever user defined span is active at that point in the workflow).

[tconley1428]

It's the same change I am making for startActivity essentially, the activity execution isn't parented to the startActivity, it's parented to the workflow, because really the start has already completed.

[cretz]

I think it is misleading to parent the child workflow execution to the signal span

It's not parenting a child workflow execution, it's parenting the child signal handler in this case (though in some cases it does). Not sure I agree here necessarily. At least in OTel at TracingWorkflowInboundInterceptor.handle_signal, we have chosen to model the signal span as "linked", not the parent, but in the absence of a concept of linking, I think the hierarchy should represent the most targeted span out there regardless of span duration.

It doesn't make sense to me that you have a bunch of orphan outbound spans just on a common workflow span and orphan inbound spans just on a common workflow span that don't relate to each other when they actually do relate to each other. It is totally reasonable in tracing contexts to have a starting span be the parent of the thing it starts even if the start was quick.

[tconley1428]

I would argue that execution just isn't a child of the start in the normal sense. If we wanted to make a new span which covered the entire lifetime of the activity and was the parent of both start and execute, we could, though I don't really see the benefit that would provide. Doing so will also get us back in the detach handling game.

[cretz]

It is a child in the normal sense, a child when you start workflow (top-level from client or child workflow from workflow), a child when you start activity (top-level on standalone activities or regular activity from workflow), a child when you start Nexus operation, etc, etc. This is how OTel tracing is done.

I think in this case, the consistency of matching SDK behavior elsewhere is valuable.

[tconley1428]

Okay. Would you agree with the other portion of the change that even if startActivity is the parent of executeActivity, it should terminate when the scheduling is completed?

[cretz]

In OTel, since we can't have an in-workflow duration, it's completed even before scheduling completed. There is no concept of "start completed", so IMO it makes sense for startActivity to span the entire run of the activity including all attempts, and executeActivity is actually per attempt (you can have 0 or many executeActivity spans in a startActivity).

So it's hard to say since OpenAI tracing is unique in that it lets us represent durations accurately. May be worth checking what TypeScript does here in OTel since that's the only other SDK I know of that lets us track span durations accurately. IMO, spans for starting activity, child, nexus op, signaling, etc should last their entire duration if they can, even though it is called "start" in the name to match our OTel span naming conventions. But it's not a strong opinion.