-
Notifications
You must be signed in to change notification settings - Fork 3.4k
[azure-ai-projects] Support an HTTPX async transport for AnyIO/Trio applications #49154
Copy link
Copy link
Open
Labels
AI ProjectsClientThis issue points to a problem in the data-plane of the library.This issue points to a problem in the data-plane of the library.customer-reportedIssues that are reported by GitHub users external to the Azure organization.Issues that are reported by GitHub users external to the Azure organization.questionThe issue doesn't require a change to the product in order to be resolved. Most issues start as thatThe issue doesn't require a change to the product in order to be resolved. Most issues start as that
Description
Activity
Metadata
Metadata
Assignees
Labels
AI ProjectsClientThis issue points to a problem in the data-plane of the library.This issue points to a problem in the data-plane of the library.customer-reportedIssues that are reported by GitHub users external to the Azure organization.Issues that are reported by GitHub users external to the Azure organization.questionThe issue doesn't require a change to the product in order to be resolved. Most issues start as thatThe issue doesn't require a change to the product in order to be resolved. Most issues start as that
Motivation
Microsoft Agent Framework is assessing support for applications running on either asyncio or Trio through AnyIO. Its Foundry integration uses
azure.ai.projects.aio.AIProjectClient(andazure.ai.inference.aiofor embeddings). The currentazure-ai-projectspackage explicitly requiresaiohttp, and these async clients useazure-core's pipeline, whose default async transport is aiohttp. HTTPX supports both asyncio and Trio; requiring aiohttp keeps this path tied to asyncio even if the calling framework uses AnyIO.Request
Please make a supported HTTPX-based async transport available end to end for
azure-ai-projects(and coordinate withazure-ai-inferenceand async identity/credential paths where needed), so callers can use Foundry async clients under Trio without requiring aiohttp. Replacing the default aiohttp transport with HTTPX would meet the need; if a change of default is too disruptive, a stable, documented HTTPX transport option that avoids a mandatory aiohttp dependency would also work. Preserve the existing asyncio path.An application should be able to run the same
AIProjectClientoperation withanyio.run(main, backend="asyncio")andanyio.run(main, backend="trio"), including authentication, concurrent requests, response streaming, and clean cancellation/close. A transport substitution alone is insufficient if another layer still creates asyncio-only resources.Related work and references
azure-corerequest: Add HttpxTransport support for SDK #41382 (stable HTTPX transport/default selection). This issue is specifically about Foundry SDK usability and end-to-end tests once the core transport is available.azure-ai-projectsdependency on aiohttp: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/ai/azure-ai-projects/pyproject.tomlazure.core.AsyncPipelineClient: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/ai/azure-ai-projects/azure/ai/projects/aio/_client.pyAsyncHttpXTransport, but thecorehttpHTTPX transport documented separately is not an interchangeable transport for theseazure-coreclients: https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/core/azure-core-experimental