[azure-search-documents] Enable HTTPX async transport for AnyIO/Trio callers

[eavanvalkenburg]

Motivation

Microsoft Agent Framework is exploring AnyIO support so its Python agents can run with either asyncio or Trio. Its Azure AI Search integration uses azure.search.documents.aio.SearchClient and azure.search.documents.indexes.aio.SearchIndexClient (and, when available, the async knowledge-base retrieval client). These clients depend on azure-core; the default azure-core async HTTP transport uses aiohttp, which is asyncio-specific. Agent Framework currently lists aiohttp explicitly for this integration as a consequence. HTTPX's async client supports both asyncio and Trio.

Request

Please provide a supported, documented HTTPX async transport for azure-search-documents, rather than requiring the aiohttp transport to use its async clients. If changing the azure-core async default from aiohttp to HTTPX is acceptable, that would address this; otherwise a stable azure-core HTTPX transport option that can be selected without bringing in aiohttp would suffice. Please include the async Search, index-management, and knowledge-base paths, plus credentials/transport ownership and cleanup, in the backend-compatibility assessment.

The useful acceptance check is the same representative async Search/index operation run under anyio.run(main, backend="asyncio") and anyio.run(main, backend="trio") with no asyncio-only transport in the Trio path (both key-based and async token credentials where supported). This is a request for end-to-end support, not an assertion that substituting one HTTP client alone makes every SDK layer Trio-compatible.

Related work and references

• Shared azure-core HTTPX transport request: Add HttpxTransport support for SDK #41382. This issue tracks the Azure AI Search client-level support and coverage.
• azure-search-documents depends on azure-core: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/search/azure-search-documents/pyproject.toml
• Async client pipeline: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/search/azure-search-documents/azure/search/documents/aio/_client.py
• Agent Framework integration manifests its current aiohttp dependency: https://github.com/microsoft/agent-framework/blob/main/python/packages/azure-ai-search/pyproject.toml
• HTTPX backend support: https://www.python-httpx.org/async/#supported-async-environments

[github-actions]

Thank you for your feedback. Tagging and routing to the team member(s) best able to assist.

//cc: efrainretana lc48t (@lc48t) Matt (@mattgotteiner)

[github-actions]

🎯 Agentic Issue Triage

Summary: The author requests a supported, documented HTTPX async transport for azure-search-documents (or a change to azure-core's default async transport) so that async Search clients can run under both asyncio and Trio via AnyIO, without requiring aiohttp.

📋 Issue Details

Package: azure-search-documents (depends on azure-core)
Affected API: azure.search.documents.aio.SearchClient, azure.search.documents.indexes.aio.SearchIndexClient, and (when available) the async knowledge-base retrieval client
Scenarios:

• Running async Search/index operations under anyio.run(main, backend="asyncio")
• Running the same operations under anyio.run(main, backend="trio") without any asyncio-only transport (e.g., aiohttp) in the path

Root ask: A documented HTTPX-based async transport option for azure-search-documents (or a change to azure-core's async default) that avoids a hard dependency on aiohttp, enabling Trio compatibility for consumers like Microsoft Agent Framework.

🔎 Debugging / Reproduction Notes

This is a feature/enhancement request rather than a bug report; no reproduction steps or error output are provided. The issue links a related, broader tracking issue (#41382) for a shared azure-core HTTPX transport across SDKs, plus pointers to the async client pipeline code and an external consumer (microsoft/agent-framework) that currently depends on aiohttp as a workaround.

Suggested investigation steps:

1. Review the status of the shared azure-core HTTPX transport effort tracked in Add HttpxTransport support for SDK #41382 to determine if azure-search-documents can adopt it once available.
2. Assess whether azure-search-documents' async pipeline (aio/_client.py) can accept a pluggable transport (including HTTPX) today, and whether documentation gaps exist.
3. Evaluate credential/transport lifecycle (ownership, cleanup) implications of swapping transports for async key-based and token credential flows.

🏷️ Label Confidence

• Category: Client — The issue concerns the data-plane azure-search-documents package's async client behavior, not a management-plane (azure-mgmt-*) library.
• Service: Search — The issue explicitly names azure-search-documents and links to its source under /sdk/search/.
• Confidence: High — The package and directory are unambiguous, and this Client+Search pairing matches the pattern seen in multiple prior quality reference issues for this package.

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Search (line 392) — Bottom-to-top scan found this as the first (and only) entry matching the predicted service label "Search".
• AzureSdkOwners: @hizixin (listed for this entry)
• ServiceOwners: @efrainretana, @lc48t, @mattgotteiner
• Routing action: Added "Service Attention" and "needs-team-attention" labels; left issue unassigned; pinged ServiceOwners via mention.
• Scan notes: No other %Search entries were found elsewhere in CODEOWNERS during the scan; this was the sole match.

Note: The matched entry lists both an AzureSdkOwner and ServiceOwners. A human reviewer may wish to confirm whether @hizixin should instead be assigned directly per standard AzureSdkOwners-priority routing.

Generated by Agentic Triage for #49155 · copilot · sonnet50 · 35 AIC · ⌖ 8.67 AIC · ⊞ 13.3K · ◷

[kashifkhan]

Eduard van Valkenburg (@eavanvalkenburg) Azure core allows folks to pass in a custom transport in to any of the generated http clients as such https://devblogs.microsoft.com/azure-sdk/custom-transport-in-python-sdk-an-httpx-experiment/. The client libraries already support caller-provided transports through  transport= . The consuming application or integration can implement an sync & async HTTPX transport and pass it to the generated clients; no Search- or Core-specific HTTPX implementation is required.

We tried shipping core with anyio support and ran into two big problems:

• customers were unhappy with the addition of it and the dependencies it brought along. Many of them were blocked in their enterprise environments
• There were severe performance drops with locks and networks calls, which still exist from what I understand.

we ended up removing it subsequently.