Blocking the event loop since 3.x ?

[vmaurin]

Confirm this is an issue with the Python library and not an underlying OpenAI API

• This is an issue with the Python library

Describe the bug

We run a service using a standard asyncio event loop, running various async code like aiokafka, redis (async) or aiohttp. After upgrading to 3.x version, we notice after a while symptoms that the event loop is blocked:

• timeout accessing redis
• timeout with the aiokafka coordinator/heartbeat co-routine

We tried using the default httpx2 client or httpx2 aiohttp client, but it doesn't solve the issue. Reverting to 2.54 solves the issue

Sorry to be so vague, we have nothing in our logs that could give a pointer to a more precise section of the code. We do use chat completion APIs, and structured output with Pydantic

To Reproduce

1. Update to 3.x
2. Wait few hours, the CPU usage is raising, symptom of blocked event loop appears

Code snippets

OS

Linux x86

Python version

Python v3.12.3

Library version

OpenAI v3.6.0

[jbeckwith-oai]

Thanks for the report. We tried to reproduce this against the reported version boundary, but we have not been able to trigger a 3.x-specific event-loop blockage yet.

What we tried:

• Compared v2.54.0 and v3.6.0 with release-era pinned dependencies.
• Ran a local, deterministic HTTP/1.1 server so API/network latency was not a variable.
• Exercised AsyncOpenAI().chat.completions.parse(...) with a reused client under concurrency, using both a small Pydantic response and a roughly 49 KB structured response.
• Tested v3.6.0 with its default HTTPX2 client, DefaultAioHttpClient(), and the documented injected legacy httpx.AsyncClient() escape hatch.
• Repeated the main matrix in a Linux/amd64 Python 3.12 container.
• Measured event-loop lag, CPU time, RSS, and live asyncio task count over thousands of requests.
• Also stress-tested constructing unclosed clients repeatedly.

In those runs, reused clients did not accumulate tasks or memory, and v3.6.0 was not slower or more starved than v2.54.0. Repeatedly constructing clients without explicitly closing them did create pressure, but it was worse with v2.54.0, so that did not match this report. We can reproduce bounded loop lag from synchronous JSON/Pydantic parsing under extreme local throughput, but that behavior is not specific to 3.x and did not worsen over time.

The v3.0 HTTPX2 migration remains the most relevant version-boundary change, but both v3.6.0 transport choices still share the HTTPX2-facing client layer. Could you help us isolate it with the following?

1. Please share the exact resolved versions, ideally the relevant lines from pip freeze or your lockfile: openai, httpx2, httpcore2, httpx, aiohttp, anyio, jiter, and pydantic, plus your Linux distribution and whether you use uvloop.

2. Please share a minimized version of client construction and the OpenAI call site. In particular: is one AsyncOpenAI client reused for the process lifetime, or is a new client created per request? How and when is it closed?

3. Which API path is involved: chat.completions.create, chat.completions.parse, streaming, or a mix? Are Pydantic model classes static or dynamically created? Rough response size, request rate, and peak OpenAI concurrency would help.

4. Does v3.6.0 still reproduce when you explicitly inject a legacy HTTPX client?

   from typing import Any, cast
   import httpx
   from openai import AsyncOpenAI
   
   client = AsyncOpenAI(http_client=cast(Any, httpx.AsyncClient()))

   If this is healthy while the default HTTPX2 and aiohttp configurations fail, that would strongly isolate the regression to the HTTPX2/common-client layer.

5. During the high-CPU window, could you capture a 30–60 second CPU profile or stack sample (py-spy top, py-spy record, or py-spy dump) and an asyncio task dump? Please redact request bodies, headers, keys, and customer data. The hottest stack frames are the most important evidence.

6. Please describe the failure shape: does one process/core reach 100% CPU, does RSS continually increase, how much event-loop lag do you observe, and does the process recover if OpenAI traffic is paused?

7. Are proxies, custom transports, tracing/instrumentation hooks, TLS settings, or retry overrides involved?

With either the legacy-HTTPX result or a redacted hot-stack profile, we should be able to reduce this to a reliable reproducer much more quickly.

[vmaurin]

Thank for the investigation @jbeckwith-oai

About testing, it is happening mainly for us on our real production, interacting with the OpenAI standard endpoints. We observe it is "ramping up" over ~12 hours, at first it is barely visible, then it becomes worse and worse. We usually see also in logs "Retry after" so a local, deterministic HTTP/1.1 server might not be an ideal test case. Maybe something is going wrong with the request retry logic and pilling up here.

Linux is a ubuntu 24.04 in a container. The host machine is an AWS ECS fargate task (hard to know tons of details)
For uvloop, we have actually a task running with and one running a vanilla asyncio and we see the CPU ramping up in both scenario (so it doesn't look to impact)

  Declared in pyproject.toml (all exact pins)

  "pydantic[email]==2.13.5"
  "aiohttp==3.14.3"
  "openai[aiohttp]==3.6.0"
  httpx, httpx2, httpcore2, anyio, jiter are transitive — not declared directly.

  Resolved entries

  [[package]]
  name = "openai"
  version = "3.6.0"
  source = { registry = "https://pypi.org/simple" }
  dependencies = [
      { name = "anyio" },
      { name = "httpx2" },
      { name = "jiter" },
      { name = "pydantic" },
      { name = "sniffio" },
      { name = "typing-extensions" },
  ]
  sdist = { url = ".../openai-3.6.0.tar.gz", hash = "sha256:18fe3f6e96390ef41ee27b152fc9effefca321c33673bd9b956a572493d3ab9b", size = 1455376, upload-time = "2026-08-28T22:29:18.268Z" }

  [package.optional-dependencies]
  aiohttp = [ { name = "aiohttp" } ]     # ← the [aiohttp] extra we enable

  [[package]]
  name = "httpx2"
  version = "2.12.0"
  dependencies = [
      { name = "anyio", marker = "sys_platform != 'emscripten'" },
      { name = "httpcore2", marker = "sys_platform != 'emscripten'" },
      { name = "httpx2-jsfetch", marker = "sys_platform == 'emscripten'" },
      { name = "idna" },
      { name = "truststore", marker = "sys_platform != 'emscripten'" },
      { name = "typing-extensions", marker = "python_full_version < '3.13'" },
  ]
  sdist hash = "sha256:7631fe9887a8a2275f4a2540e053aa670fcc50742864a9ae7c66e609fdcf12cf"  # 2026-08-18

  [[package]]
  name = "httpcore2"
  version = "2.12.0"
  dependencies = [ { name = "h11" }, { name = "truststore" } ]
  sdist hash = "sha256:9293522bba0aa7c4c8e9e3f040c16575bd8868e155a77fa30c7a9085a5eae648"  # 2026-08-18

  [[package]]
  name = "httpx"
  version = "0.28.1"
  dependencies = [ { name = "anyio" }, { name = "certifi" }, { name = "httpcore" }, { name = "idna" } ]
  sdist hash = "sha256:75e98c5f16b0f35b567856f597f06ff2270a374470a5c2392242528e3e3e42fc"  # 2024-12-06

  [[package]]
  name = "httpcore"
  version = "1.0.9"
  dependencies = [ { name = "certifi" }, { name = "h11" } ]
  sdist hash = "sha256:6e34463af53fd2ab5d807f399a9b45ea31c3dfa2276f15a2c3f00afff6e176e8"  # 2025-04-24

  [[package]]
  name = "aiohttp"
  version = "3.14.3"
  dependencies = [ aiohappyeyeballs, aiosignal, attrs, frozenlist, multidict, propcache,
                   typing-extensions (py<3.13), yarl ]
  sdist hash = "sha256:9491196535a88924a60afd5b5f434b5b203b6cc616250878dbdb223a8f7844bc"  # 2026-07-23

  [[package]]
  name = "anyio"
  version = "4.14.2"
  dependencies = [ { name = "idna" }, { name = "typing-extensions", marker = "python_full_version < '3.13'" } ]
  sdist hash = "sha256:cfa139f3ed1a23ee8f88a145ddb5ac7605b8bbfd8592baacd7ce3d8bb4313c7f"  # 2026-07-12

  [[package]]
  name = "jiter"
  version = "0.16.0"
  # no dependencies
  sdist hash = "sha256:7b24c3492c5f4f84a37946ad9cf504910cf6a782d6a4e0689b6673c5894b4a1c"  # 2026-06-29

  [[package]]
  name = "pydantic"
  version = "2.13.5"
  dependencies = [ annotated-types, pydantic-core, typing-extensions, typing-inspection ]
  sdist hash = "sha256:51a9c5f7b2f8e636f04c6cada605d9b6a3bf1348fdf945a3d8869b19bba0ee08"  # 2026-08-28
  [package.optional-dependencies]
  email = [ { name = "email-validator" } ]   # ← the [email] extra we enable

  [[package]]
  name = "pydantic-core"
  version = "2.46.5"
  dependencies = [ { name = "typing-extensions" } ]
  sdist hash = "sha256:10416c15b8839ecc4ef4d0885da76da6fd0f67333a0eb8aff6d93c4b8f2910fc"  # 2026-08-28

We observed the issue with both

        self._client = AsyncOpenAI(api_key=api_key, organization=organization, _enforce_credentials=False)

and

        self._client = AsyncOpenAI(
            api_key=api_key, organization=organization, _enforce_credentials=False, http_client=DefaultAioHttpClient()
        )

We create a single client for the whole process that is reused during the full process timeline

We are using client.chat.completions.create
Then we have a mix of no structured output, and structured output.
For structured output, we create a class per request, with a code like this

    @staticmethod
    def _create_categorization_response_class(labels, field_ids):
        class Categorization(BaseModel, extra="forbid"):
            category: Annotated[str, DynamicStrEnum(labels)]
            confidence: Annotated[str, DynamicStrEnum(CONFIDENCES.keys())]
            field: Annotated[
                str,
                DynamicStrEnum(["*", *field_ids]),
                Field(description="a field id, it could be `*` for the whole content"),
            ]

        class CategorizationResponse(BaseModel, extra="forbid"):
            categorizations: list[Categorization]

        return CategorizationResponse

At peak we are around 700 RPM on OpenAI, but we do have multiple task running, so more realistically, on each task it is probably less than 100 RPM. Output tokens are rather small, Input tokens probably around ~1000 in average (but we have big variations)

4 and 5, yet to try

6. We run our process on a single CPU fargate task. At first the CPU usage is normal, and no symptom of blocked event loop. Then the CPU is ramping up and we are seeing more and more sign of blocked event loop

(spike are when we release a new version at 10:00 we tried again 3.x with aiohttp and we roll backed at 21:00)

7. No

[Hughhhhcoder]

I ran an isolated check against the current source with the reported dependency versions: httpx2 2.12.0, pydantic 2.13.5, anyio 4.14.2, and aiohttp 3.14.3. The test made 2,000 sequential chat.completions.parse calls, created one new Pydantic response model per call, and returned a 429 with Retry-After on every 11th transport call. The async task count stayed at 1 throughout. RSS rose during the first 500 calls and then stayed at the same high-water mark through 2,000 calls. This does not reproduce a continuing SDK-side retry-task buildup, although a local MockTransport cannot rule out a production transport or server interaction. The current request path closes retryable responses before sleeping. A useful next discriminator would be a redacted profile comparing max_retries=0 with the default and an explicitly injected legacy HTTPX client. I do not have a stable SDK code defect to patch yet.

[aktaseren]

For anyone affected by this, it looks like there isn’t enough evidence yet to confirm a 3.x-specific event-loop regression.

As a temporary workaround, it may be worth testing with max_retries=0 and/or the legacy HTTPX client to see whether the behaviour changes. If either makes a difference, sharing the results here would help narrow down the cause. A CPU/asyncio profile during the CPU ramp-up would also be very useful for identifying where the event loop is being blocked.