Add durable orchestration InstanceId to Operation Name in Application Insights

[bdebaere]

What problem would the feature you're requesting solve? Please describe.

As far as I'm aware, when using Durable Functions with Application Insights in the .NET Isolated worker model, it’s currently not possible to have the Durable Orchestration Instance ID included in the Application Insights Operation Name (operation_Name).

This becomes a real problem when diagnosing failures in Application Insights. In the Failures tab, all orchestrations appear under the same Operation Name, so when multiple orchestrations fail at once, every failure is aggregated together.

To dig into a specific orchestration run, you have to manually open and inspect individual samples one by one, since there’s no easy way to tell from the Operation Name which instance a failure belongs to without drilling down into each exception or trace entry.

If the Operation Name included the orchestration’s InstanceId, failures could be grouped and identified instantly, greatly improving debugging efficiency and observability.

Describe the solution you'd like

A possible solution could be if the Durable Functions host or its Application Insights integration automatically included the Durable Orchestration InstanceId as part of the operation_Name for telemetry. But that may not be ideal for everyone. This would allow Application Insights to treat each orchestration execution as its own distinct operation, making it far easier to trace failures, analyze telemetry, and correlate activity and exception data for that specific orchestration run.

Alternatively, it would be just as helpful to have a supported way to customize or intercept RequestTelemetry (e.g., a working TelemetryInitializer or TelemetryProcessor) in the .NET Isolated worker model, so developers could append the instance ID themselves.

Alternatively, suggest an alternate approach where I can have AI aggregate the results the way I want where I can easily identify which Instance ID is failing.

Describe alternatives you've considered

TelemetryInitializer / TelemetryProcessor approaches:
Attempting to intercept and modify RequestTelemetry using these mechanisms works fine in the in-process Functions model but does not work in the isolated worker model, at least not for function request telemetry.

Example (that fails to apply in isolated functions):

public class DurableInstanceTelemetryInitializer : ITelemetryInitializer
{
    public void Initialize(ITelemetry telemetry)
    {
        if (telemetry is RequestTelemetry request)
        {
            var instanceId = ...;
            if (!string.IsNullOrEmpty(instanceId))
            {
                request.Context.Operation.Name = $"{request.Context.Operation.Name} ({instanceId})";
            }
        }
    }
}

Manually logging the InstanceId as a custom dimension or within the message text works for ad-hoc searches, but it doesn’t affect how AI aggregates requests, dependencies, or failures — so it doesn’t solve the discoverability issue.