Add durable instance-id logging scopes for orchestrations and activities

[Copilot]

Durable Functions logs lacked automatic instance-id scoping, making correlation across orchestrators and activities cumbersome.

• Logging scopes

  • Wrap orchestrator execution (TaskOrchestrationShim) in a logger scope containing InstanceId.
  • Wrap activity execution (TaskActivityShim) in the same instance-id scope before invoking user code.

• Tests

  • Added shim-level tests verifying the logger scope captures the expected InstanceId for orchestrations and activities.

Example scope usage now applied automatically:

// inside orchestration/activity shims
using this.logger.BeginScope(new Dictionary<string, object?> { ["InstanceId"] = instanceId })
{
    // user code executes with instance-id in logging scope
}

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add instance id to logging scopes</issue_title>
<issue_description>Monitoring our durable workflows would be a lot easier if we'd see the corresponding instance id within app logs from orchestrators and activities in Application Insights. Ideally, all loggers in those durable functions would automatically use a scope containing the instance id.

Right now, we'd have to create our own scope in each orchestrator and also pass the instance id to each activity in order to create another logging scope there since, from my tests, the logging scope does not extend to activity invocations.

I've also looked into a middleware-based approach, however, I wasn't able to resolve the instance id reliably from FunctionContext.

As a side note, there are at least three different ways to create a logger and things unfortunately keep on changing:

• Migrate .NET apps from the in-process model to the isolated worker model - Logging: ILogger<T> via DI (for Activities only?)
• Create your first Durable Function in C#: FunctionContext.GetLogger in Activity
• Diagnostics in Durable Functions - App Logging: FunctionContext.GetLogger / TaskOrchestrationContext.CreateReplaySafeLogger

If you'd ask me, I'd say that all functions should use the conventional ILogger<T> via DI which would automatically be replay safe in orchestrators with some kind of way to obtain a non-replay safe logger for debugging purposes. I get that there are probably technical constraints for how the logger API is built though.</issue_description>

Comments on the Issue (you are @copilot in this section)

@jviau Supporting a replay-safe logger via DI is something we would like to do, however with the current design DI runs before we have access to necessary parts to create a replay-safe logger. Which is why for orchestrations, the only way to get a replay safe logger is off the `TaskOrchestrationContext`. Activities do not have the need for a replay-safe logger, so you get them whichever way suites you (DI, FunctionContext).

As for adding instance ID to logger scopes, improving observability is something we are continually working on. Right now we are focusing on distributed tracing, then it will be metrics, and after that we will come back to logs as necessary.</comment_new>

• Fixes Add instance id to logging scopes #250

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.