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.

[Copilot]

Pull request overview

This PR addresses issue #250 by adding automatic instance-id logging scopes to orchestration and activity executions in Durable Task. Previously, users had to manually create logging scopes containing the instance ID in each orchestrator and activity to correlate logs in Application Insights.

Key changes:

• Logging scopes wrapping orchestrator execution with InstanceId in TaskOrchestrationShim.Execute
• Logging scopes wrapping activity execution with InstanceId in TaskActivityShim.RunAsync
• Unit tests validating that instance-id scopes are properly applied

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
src/Worker/Core/Shims/TaskOrchestrationShim.cs	Wraps orchestration execution in a logger scope containing the InstanceId, ensuring all logs during orchestration have the instance context
src/Worker/Core/Shims/TaskActivityShim.cs	Wraps activity execution in a logger scope containing the InstanceId, ensuring all logs during activity have the instance context
test/Worker/Core.Tests/Shims/TaskShimLoggingScopeTests.cs	Adds comprehensive unit tests verifying that both orchestration and activity shims properly create logging scopes with the correct InstanceId

[Copilot]

According to the coding guidelines, all private classes that do not serve as base classes should be sealed. The TestOrchestrationContext class should be declared as sealed since it's a private helper class and doesn't serve as a base class.

[Copilot]

Duplicate namespace declaration. The namespace is already declared on line 7 (using Microsoft.DurableTask.Worker.Shims). This duplicate declaration should be removed as it's redundant and could cause confusion.

Suggested change

using Microsoft.DurableTask.Worker.Shims;

[Copilot]

According to the coding guidelines, all private classes that do not serve as base classes should be sealed. The TestActivity class should be declared as sealed since it's a private helper class and doesn't serve as a base class.

[Copilot]

According to the coding guidelines, all private classes that do not serve as base classes should be sealed. The TestOrchestrator class should be declared as sealed since it's a private helper class and doesn't serve as a base class.