Entity operations don't propagate trace context from parent orchestration

[cgillum]

Summary

When an orchestration calls an entity via CallEntityAsync(), the DTS SDK does not propagate the orchestration's trace context (ParentTraceContext) to the entity operation. This causes entity spans (and any child spans created within the entity) to appear as disconnected root traces instead of being parented under the calling orchestration's trace tree.

Root Cause

In ProtoUtils.ConstructOrchestratorResponse, ParentTraceContext = CreateTraceContext() is set for:

• ✅ ScheduleTaskAction (activities)
• ✅ CreateSubOrchestrationAction (sub-orchestrations)
• ❌ SendEntityMessageAction — no trace context is set

This means the W3C traceparent / tracestate that enables distributed trace stitching is never included in entity messages dispatched from orchestrations.

Expected Behavior

Entity operations dispatched from an orchestration should inherit the orchestration's trace context, just like activities and sub-orchestrations do. The invoke_agent spans (or any other work done inside the entity) should appear as children of the orchestration span in a trace viewer.

Actual Behavior

Entity operations start a new, independent trace. In a trace viewer (e.g., Aspire Dashboard, Jaeger), entity spans appear as separate root traces with no parent relationship to the orchestration that dispatched them.

Impact

This is particularly impactful for scenarios that use Durable Entities as the execution model for agent invocations (e.g., DurableAIAgent in the Microsoft Agent Framework). Each invoke_agent span appears disconnected from the orchestration trace, making it impossible to view the full execution tree in a single trace.

Suggested Fix

In ProtoUtils.cs, add ParentTraceContext = CreateTraceContext() to the SendEntityMessage action construction (similar to how it's done for ScheduleTask and CreateSubOrchestration). The entity work item processing path would also need to parse and restore this context when executing entity operations.

[github-actions]

Issue Triage

Classification: triage/external-dependency

Reasoning:
This issue is well-described with a clear root cause: SendEntityMessageAction in ProtoUtils.cs does not set ParentTraceContext, unlike ScheduleTaskAction and CreateSubOrchestrationAction. However, the fix requires proto definition changes in the separate durabletask-protobuf repository (adding parentTraceContext to SendEntityMessageAction, EntityOperationSignaledEvent, and EntityOperationCalledEvent). PR #654 is already open and tracks this work, and it depends on the proto changes being merged first.

Automated fix candidate: No

• Requires proto definition changes in an external repository (durabletask-protobuf)
• PR Propagate trace context for entity operations #654 already exists and is tracking this work
• The SDK-side changes cannot be completed until the proto changes are available