Repository navigation
[azure-ai-projects] Client trace instrumentation lacks Foundry project identity #48825
Description
- Package Name:
azure-ai-projects - Package Version:
2.3.0 - Operating System: Windows 11 Enterprise 10.0.26200
- Python Version: 3.13.15
Describe the bug
Client-side invoke_agent spans created through the documented AIProjectInstrumentor and Azure Monitor path do not include microsoft.foundry.project.id. The spans reach the Application Insights resource connected to the Foundry project and include gen_ai.response.id, but they are not discoverable in that agent's Foundry Traces view.
AIProjectClient exposes the project endpoint but no public project ARM resource ID. The endpoint contains the account and project names, but not the subscription ID or resource group needed to construct the full ARM ID. AIProjectInstrumentor.instrument() also has no project identity option and does not enrich its spans with this attribute.
The current workaround is to list project connections and derive the parent project resource ID from Connection.id:
connection = next(iter(project_client.connections.list()), None)
project_arm_id = connection.id.rsplit("/connections/", 1)[0] if connection else NoneThis pattern also appears in the repository's human-evaluations sample, but it is not documented for client tracing and requires an extra service call plus resource-ID parsing.
To Reproduce
Steps to reproduce the behavior:
- Create or use a Foundry project with Application Insights connected and a published Prompt Agent.
- Set
FOUNDRY_PROJECT_ENDPOINT,FOUNDRY_AGENT_NAME, andFOUNDRY_AGENT_VERSION. - Run:
import os
from azure.ai.projects import AIProjectClient
from azure.ai.projects.telemetry import AIProjectInstrumentor
from azure.identity import DefaultAzureCredential
from azure.monitor.opentelemetry import configure_azure_monitor
os.environ["AZURE_EXPERIMENTAL_ENABLE_GENAI_TRACING"] = "true"
AIProjectInstrumentor().instrument()
with (
DefaultAzureCredential() as credential,
AIProjectClient(
endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
credential=credential,
) as project_client,
):
configure_azure_monitor(
connection_string=project_client.telemetry.get_application_insights_connection_string(),
enable_live_metrics=False,
)
openai_client = project_client.get_openai_client()
openai_client.responses.create(
input="Reply with exactly OK.",
extra_body={
"agent_reference": {
"name": os.environ["FOUNDRY_AGENT_NAME"],
"version": os.environ["FOUNDRY_AGENT_VERSION"],
"type": "agent_reference",
}
},
)- Inspect the resulting
invoke_agentdependency in the connected Application Insights resource. It has the agent/response attributes, but notmicrosoft.foundry.project.id. - Open the published agent's Traces view in Foundry. The client-side trace is not listed.
- Add the full project ARM ID as
microsoft.foundry.project.idto the rootinvoke_agentspan and repeat. The client-side trace is listed.
This was also reproduced through Microsoft Agent Framework and isolated with controlled live traces in microsoft/agent-framework#7492.
Expected behavior
The supported azure-ai-projects client-tracing setup should provide a public, documented way to associate client spans with the current Foundry project so they appear in the project's Foundry Traces view.
Possible SDK-level solutions include:
- Expose the project's ARM resource ID directly from
AIProjectClient. - Add a telemetry operation that returns project identity together with the Application Insights connection information.
- Allow
AIProjectInstrumentor.instrument(project_arm_id=...)and use it to enrich generatedinvoke_agentspans. - Automatically resolve and cache project identity inside the instrumentor.
Consumers should not need to parse a child connection resource ID to obtain project identity.
Screenshots
The original Agent Framework report contains Foundry and Application Insights screenshots demonstrating the missing client trace: microsoft/agent-framework#7492.
Additional context
AIProjectInstrumentor.instrument()currently acceptsenable_content_recording,enable_trace_context_propagation, andenable_baggage_propagation, but no project identity.- The official human-evaluations sample derives
project_resource_idfromConnection.id: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/ai/azure-ai-projects/samples/evaluations/sample_human_evaluations.py - Foundry-hosted agentserver code receives
FOUNDRY_PROJECT_ARM_IDfrom the platform and emitsmicrosoft.foundry.project.id, but external client applications do not receive that environment variable automatically. - This report is specifically about Foundry trace-list discovery. HTTPX/W3C trace-context propagation is tracked separately by configure_azure_monitor() does not auto-instrument httpx — breaks distributed tracing for OpenAI SDK / Azure AI Agent Framework (MAF) #46286 and Add httpx support #47953.
Activity
github-actions commentedon Sep 3, 2026
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc retry-recv (@bobogogo1990) Darren Cohen (@dargilco) Glenn Harper (@glharper) Howie Leung (@howieleung) kingernupur Nikolay Rovinskiy (@nick863) Travis Angevine (@trangevi) Travis Wilson (@trrwilson).
dargilco commentedon Sep 3, 2026
M-Hietala to triage
jpalvarezl commentedon Sep 18, 2026
Closing this report after reproducing the problem and verifying the fix. Thanks, Marko, for helping clarify the expected behavior.
The fix for our scenario was to use
azure-monitor-opentelemetry1.8.10, which correctly instruments the OpenAI client's HTTPX/HTTPX2 transport and propagates W3Ctraceparentheaders. With 1.8.9, the client spans reached Application Insights, but the outgoing requests lacked trace context and Foundry created independent server traces.With 1.8.10, we verified that client and service spans share the same trace ID and the correct parent relationship, and that the combined tree appears in Build > Agents > the agent > Traces, including the default agent-version view. This works without client-side
microsoft.foundry.project.idstamping or copying response IDs onto outer invocation spans.The earlier conclusion that the SDK must expose project identity to fix this symptom was therefore not necessary for this reproduction. No project-identity API change is required for this scenario, so I am withdrawing that proposed fix rather than requesting further SDK work.
The focused Agent Framework dependency/setup guidance change is in jpalvarezl/agent-framework#2. The original symptom remains tracked in microsoft/agent-framework#7492 pending the upstream Agent Framework change. The experimental attribution workaround has been removed from the fork PR.