Function Invocation Details Cross Pollinating Logs from Other Function Apps

[bpalfaro]

When investigating a function's invocation, the invocation shows logging information from other functions and function apps. We have seen this happen from functions calling functions in other function apps, logic apps calling independent service bus queues with different function apps as consumers. Any insight would be appreciated on whether this is an Azure portal UI issue or a coding issue.

Investigative information

Please provide the following:

• Timestamp: 11/12/2025, 8:56:12 AM
• Function App version: 4.1044.200.25476
• Function App name:
• Function name(s) (as appropriate):
• Invocation ID: 573c2b72-db3b-44a5-9057-0a8004d1cff4
• Region: East US 2

Repro steps

Provide the steps required to reproduce the problem:

Example:

1. Execute a function A that calls a function B in a separate function app
2. In Azure portal, Navigate to the invocations of function B.
3. Invocations will list function B only.
4. Click an instance of the invocation and you will see logs from other functions that should not be present.
5. Review Application Insights on the Invocations page vs. the invocation details page. The queries are quite different and seem incorrect.

Expected behavior

Provide a description of the expected behavior.

Example:

• After I perform step 4, the invocation logs should only show logging from function B.

Actual behavior

Provide a description of the actual behavior observed.

Example:

• Step 4 actually shows logs from any operation id in the code path and will show logging from many different functions.

Known workarounds

Provide a description of any known workarounds.

Example:

Modify the application insights query and run manually.

Related information

Provide any related information

• Programming language used - .NET 8 Runtime
• Bindings used - HTTP and Service Bus bindings exhibit this behavior
• Notes: (operation id/operationid/invocation id/invocation id/cloud role name/cloud_rolename), KQL

[RohitRanjanMS]

Hi @bpalfaro , are you using a shared AppInsights resource?

The query runs on the operationId, so since both functions are part of the same operation (one calling the other), all related logs appear together. This is consistent with Azure Monitor’s behavior, where the transaction view shows all telemetry tied to a single operation.

[bpalfaro]

@RohitRanjanMS Yes, we are using a shared AppInsights resource across all our resources of our app.

On the function's Invocations screen here is the query when you click the Open in Application Insights link

requests
| extend functionNameFromCustomDimension = tostring(customDimensions["faas.name"])
| project
timestamp,
id,
operation_Name,
success,
resultCode,
duration,
operation_Id,
functionNameFromCustomDimension,
cloud_RoleName,
invocationId=coalesce(tostring(customDimensions["InvocationId"]), tostring(customDimensions["faas.invocation_id"]))
| where timestamp > ago(30d)
| where cloud_RoleName =~ 'func-app-name-here'
| where operation_Name =~ 'func-name-here' or functionNameFromCustomDimension =~ 'func-name-here'
| order by timestamp desc
| take 20

Click an Invocation link, then on the Invocations Details screen here is the query when you click the Open in Application Insights link

union traces
| union exceptions
| where timestamp > ago(30d)
| where operation_Id == '68bb34147dddc8a088ae1362dd841030'
| order by timestamp asc
| project
timestamp,
message = iff(message != '', message, iff(innermostMessage != '', innermostMessage, customDimensions.['prop__{OriginalFormat}'])),
logLevel = customDimensions.['LogLevel'],
severityLevel

Did this behavior change recently?

[RohitRanjanMS]

Another team manages this, but I don’t believe the behavior has changed. Do you have any concerns with the current approach? As mentioned, you’ll see similar telemetry when using transaction search in the AppInsights portal.

[bpalfaro]

Yes we do have concerns. We provide this information to support teams to troubleshoot our application when a function invocation fails. They click the invocation detail and the information includes erroneous information from the perspective of the interested function. We believe this was not the way this screen behaved previously. Let me know how to proceed.