All Azure Function invocations have the same operation_Id and logs are repeated

Question

All Azure Function invocations have the same operation_Id and logs are repeated

sonal khatri 91

Hi,

I have a TimerTrigger that sends messages to Service Bus (output binding). A ServiceBusTrigger processes them and sends to another topic, which triggers the next function.

Problem: different invocations show the same operation_Id, so logs from one run appear with another.

Is this expected? How can I make each invocation have its own operation_Id?

Jerald Felix 18,760 Reputation points Volunteer Moderator

2025-10-16T16:47:03.14+00:00

Hello sonal khatri,

When all Azure Function invocations show the same operation_Id and logs appear repeated across different runs, it usually indicates that the diagnostic context (such as logging scope or operation tracking) is shared or not properly initialized per execution. This is not expected—each invocation should have its own unique operation_Id for accurate tracing and debugging.

Here’s what you can do:

Ensure operation_Id assignment per invocation: Azure Functions automatically assigns a unique operation_Id to each function execution for correlation. If you are using custom logging or programmatically setting telemetry context, make sure you’re not reusing the same operation_Id object across triggers or invocations.

Check custom telemetry or middleware: If you manipulate correlation/telemetry context (such as with Application Insights TelemetryClient), do not use global/static references for OperationContext or Activity. Always generate new identifiers per invocation.

Durable Functions caveat: In orchestrations or chained triggers (like Timer > Service Bus > Topic > another Function), operation_Id might be propagated if explicitly passed along. But by default, each Azure Function instance invocation gets a new one.

If you still see the issue, review any global variables or singleton services in your code that may impact how operation_Id is managed in your logging framework.

Let me know if you need help with implementation code or more in-depth troubleshooting.

Best Regards,

Jerald Felix

sonal khatri 91

Hi @Jerald Felix

This is my code for adding logging to the application. Also, I am not using any custom middleware


    private static IHostApplicationBuilder AddLoggingServices(this IHostApplicationBuilder builder, string applicationName)
    {
        builder.Logging.AddSimpleConsole();
        builder.Services
            .AddApplicationInsightsTelemetryWorkerService()
            .ConfigureFunctionsApplicationInsights();

        builder.Logging.Services.Configure<LoggerFilterOptions>(options =>
        {
            // The Application Insights SDK adds a default logging filter that instructs ILogger to capture only Warning and more severe logs. Application Insights requires an explicit override.
            // Log levels can also be configured using appsettings.json. For more information, see https://learn.microsoft.com/azure/azure-monitor/app/worker-service#ilogger-logs
            LoggerFilterRule? defaultRule = options.Rules.FirstOrDefault(
                rule => rule.ProviderName == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
            if (defaultRule is not null)
            {
                options.Rules.Remove(defaultRule);
            }
        });

        return builder;
    }

Your answer

Jerald Felix 18,760 Reputation points Volunteer Moderator

2025-10-16T16:47:03.14+00:00

Hello sonal khatri,

When all Azure Function invocations show the same operation_Id and logs appear repeated across different runs, it usually indicates that the diagnostic context (such as logging scope or operation tracking) is shared or not properly initialized per execution. This is not expected—each invocation should have its own unique operation_Id for accurate tracing and debugging.

Here’s what you can do:

Ensure operation_Id assignment per invocation: Azure Functions automatically assigns a unique operation_Id to each function execution for correlation. If you are using custom logging or programmatically setting telemetry context, make sure you’re not reusing the same operation_Id object across triggers or invocations.

Check custom telemetry or middleware: If you manipulate correlation/telemetry context (such as with Application Insights TelemetryClient), do not use global/static references for OperationContext or Activity. Always generate new identifiers per invocation.

Durable Functions caveat: In orchestrations or chained triggers (like Timer > Service Bus > Topic > another Function), operation_Id might be propagated if explicitly passed along. But by default, each Azure Function instance invocation gets a new one.

If you still see the issue, review any global variables or singleton services in your code that may impact how operation_Id is managed in your logging framework.

Let me know if you need help with implementation code or more in-depth troubleshooting.

Best Regards,

Jerald Felix
sonal khatri 91 Reputation points

2025-10-17T02:42:26.0333333+00:00

Hi @Jerald Felix

This is my code for adding logging to the application. Also, I am not using any custom middleware

private static IHostApplicationBuilder AddLoggingServices(this IHostApplicationBuilder builder, string applicationName) { builder.Logging.AddSimpleConsole(); builder.Services .AddApplicationInsightsTelemetryWorkerService() .ConfigureFunctionsApplicationInsights(); builder.Logging.Services.Configure<LoggerFilterOptions>(options => { // The Application Insights SDK adds a default logging filter that instructs ILogger to capture only Warning and more severe logs. Application Insights requires an explicit override. // Log levels can also be configured using appsettings.json. For more information, see https://learn.microsoft.com/azure/azure-monitor/app/worker-service#ilogger-logs LoggerFilterRule? defaultRule = options.Rules.FirstOrDefault( rule => rule.ProviderName == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider"); if (defaultRule is not null) { options.Rules.Remove(defaultRule); } }); return builder; }