Issue Station
Sign In
Tools hereToolbox

langchain - ✅(Solved) Fix AzureChatOpenAI does not reuse default httpx clients like BaseChatOpenAI [1 pull requests, 4 comments, 5 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
langchain-ai/langchain#36259•Fetched 2026-04-08 01:31:05
View on GitHub
Comments
4
Participants
5
Timeline
16
Reactions
0
Author
zhongyunWanzhongyunWan
Participants
fairchildadrian9-createfairchildadrian9-createjasieckyjasieckymajorelalexis-stackmajorelalexis-stacksatishkc7satishkc7zhongyunWanzhongyunWan
Timeline (top)
commented ×4mentioned ×4subscribed ×4cross-referenced ×2

BaseChatOpenAI reuses default httpx clients across instances via _get_default_httpx_client() and _get_default_async_httpx_client(), which allows connection pooling and reduces resource overhead.

However, AzureChatOpenAI does not follow this pattern. In its validate_environment method, when no custom http_client or http_async_client is provided, it passes None directly to the OpenAI SDK, causing each instance to create a brand-new httpx client. This means:

  • No connection reuse across multiple AzureChatOpenAI instances
  • Unnecessary resource consumption from redundant connection pools

Root Cause

BaseChatOpenAI reuses default httpx clients across instances via _get_default_httpx_client() and _get_default_async_httpx_client(), which allows connection pooling and reduces resource overhead.

However, AzureChatOpenAI does not follow this pattern. In its validate_environment method, when no custom http_client or http_async_client is provided, it passes None directly to the OpenAI SDK, causing each instance to create a brand-new httpx client. This means:

  • No connection reuse across multiple AzureChatOpenAI instances
  • Unnecessary resource consumption from redundant connection pools

Fix Action

Fixed

PR fix notes

PR #36142: fix(openai): reuse default httpx clients in AzureChatOpenAI

Description (problem / solution / changelog)

Fixes #36259

Description

AzureChatOpenAI does not reuse default httpx clients like BaseChatOpenAI. When no custom http_client / http_async_client is provided, it passes None to the OpenAI SDK, causing each instance to create a new httpx client instead of sharing the default one.

This PR makes AzureChatOpenAI.validate_environment fall back to _get_default_httpx_client() / _get_default_async_httpx_client() when no custom client is set, aligning behavior with BaseChatOpenAI.

Changes

  • azure.py: Use _get_default_httpx_client / _get_default_async_httpx_client as fallback when http_client / http_async_client is None
  • test_azure.py: Add test verifying two AzureChatOpenAI instances share the same default httpx clients

Changed files

  • libs/partners/openai/langchain_openai/chat_models/azure.py (modified, +16/-2)
  • libs/partners/openai/tests/unit_tests/chat_models/test_azure.py (modified, +22/-0)

Code Example

from langchain_openai import AzureChatOpenAI

llm1 = AzureChatOpenAI(
    api_key="xyz",
    azure_endpoint="https://example-resource.openai.azure.com/",
    azure_deployment="gpt-4o-mini",
    openai_api_version="2024-05-01-preview",
)
llm2 = AzureChatOpenAI(
    api_key="xyz",
    azure_endpoint="https://example-resource.openai.azure.com/",
    azure_deployment="gpt-4o-mini",
    openai_api_version="2024-05-01-preview",
)

# These should be the same object but are not:
assert llm1.root_client._client is llm2.root_client._client  # Fails
RAW_BUFFERClick to expand / collapse

Description

BaseChatOpenAI reuses default httpx clients across instances via _get_default_httpx_client() and _get_default_async_httpx_client(), which allows connection pooling and reduces resource overhead.

However, AzureChatOpenAI does not follow this pattern. In its validate_environment method, when no custom http_client or http_async_client is provided, it passes None directly to the OpenAI SDK, causing each instance to create a brand-new httpx client. This means:

  • No connection reuse across multiple AzureChatOpenAI instances
  • Unnecessary resource consumption from redundant connection pools

Expected behavior

AzureChatOpenAI should fall back to the shared default httpx clients (via _get_default_httpx_client / _get_default_async_httpx_client) when no custom client is provided, consistent with BaseChatOpenAI.

Reproduction

from langchain_openai import AzureChatOpenAI

llm1 = AzureChatOpenAI(
    api_key="xyz",
    azure_endpoint="https://example-resource.openai.azure.com/",
    azure_deployment="gpt-4o-mini",
    openai_api_version="2024-05-01-preview",
)
llm2 = AzureChatOpenAI(
    api_key="xyz",
    azure_endpoint="https://example-resource.openai.azure.com/",
    azure_deployment="gpt-4o-mini",
    openai_api_version="2024-05-01-preview",
)

# These should be the same object but are not:
assert llm1.root_client._client is llm2.root_client._client  # Fails

Suggested fix

In AzureChatOpenAI.validate_environment, fall back to _get_default_httpx_client() / _get_default_async_httpx_client() when self.http_client / self.http_async_client is None.

extent analysis

Fix Plan

To fix the issue, we need to modify the validate_environment method in AzureChatOpenAI to use the default httpx clients when no custom client is provided. Here are the steps:

  • Modify the validate_environment method to check if self.http_client and self.http_async_client are None.
  • If they are None, use the _get_default_httpx_client() and _get_default_async_httpx_client() methods to get the default httpx clients.
  • Pass these default clients to the OpenAI SDK.

Example code:

from langchain_openai import BaseChatOpenAI

class AzureChatOpenAI(BaseChatOpenAI):
    # ...

    def validate_environment(self):
        # ...
        if self.http_client is None:
            self.http_client = self._get_default_httpx_client()
        if self.http_async_client is None:
            self.http_async_client = self._get_default_async_httpx_client()
        # ...

Verification

To verify that the fix worked, you can run the reproduction code again and check that the assertion passes:

llm1 = AzureChatOpenAI(
    api_key="xyz",
    azure_endpoint="https://example-resource.openai.azure.com/",
    azure_deployment="gpt-4o-mini",
    openai_api_version="2024-05-01-preview",
)
llm2 = AzureChatOpenAI(
    api_key="xyz",
    azure_endpoint="https://example-resource.openai.azure.com/",
    azure_deployment="gpt-4o-mini",
    openai_api_version="2024-05-01-preview",
)

assert llm1.root_client._client is llm2.root_client._client  # Should pass

Extra Tips

  • Make sure to test the fix thoroughly to ensure that it does not introduce any new issues.
  • Consider adding a test case to the test suite to ensure that the fix is not reverted in the future.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

AzureChatOpenAI should fall back to the shared default httpx clients (via _get_default_httpx_client / _get_default_async_httpx_client) when no custom client is provided, consistent with BaseChatOpenAI.

#api#orchestration issue#cache issue#memory leak#API versioning

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

langchain - ✅(Solved) Fix AzureChatOpenAI does not reuse default httpx clients like BaseChatOpenAI [1 pull requests, 4 comments, 5 participants]