Skip to content

[pull] main from openai:main - #119

Merged
pull[bot] merged 2 commits into
gitupdates:mainfrom
openai:main
Jul 31, 2026
Merged

[pull] main from openai:main#119
pull[bot] merged 2 commits into
gitupdates:mainfrom
openai:main

Conversation

@pull

@pull pull Bot commented Jul 31, 2026

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

tescherm-openai and others added 2 commits July 30, 2026 15:14
## Summary

- honor positive, finite `Retry-After` delays up to 120 seconds
- treat longer server-directed delays as non-retryable instead of
substituting short exponential backoff
- keep exponential backoff for zero, negative, non-finite, missing, or
malformed values
- cover sync and async clients with numeric seconds, milliseconds, and
HTTP-date boundaries

## Motivation

The Python SDK currently ignores `Retry-After` values above 60 seconds
and falls back to a much shorter exponential delay. Historical
reset-header data shows that common minute-scale waits can land just
above 60 seconds, while extending the ceiling beyond two minutes adds
little coverage before waits jump to hours or days.

## Developer impact

Clients with automatic retries enabled will honor server-directed delays
through two minutes. If `Retry-After` exceeds two minutes, the SDK
surfaces the API error instead of blocking a synchronous worker for an
extended period or retrying before the requested time. Retry attempts
remain bounded by `max_retries`.

## Validation

- `.venv/bin/ruff format --check src/openai/_constants.py
src/openai/_base_client.py tests/test_client.py`
- `.venv/bin/ruff check src/openai/_constants.py
src/openai/_base_client.py tests/test_client.py`
- `.venv/bin/pytest -q tests/test_client.py` (198 passed, 2 skipped)
## Summary

- document API-key HTTP mTLS using native `ssl.SSLContext` configuration
and the existing custom `http_client` seam
- add standalone sync and async examples for HTTPX and experimental
HTTPX2
- verify all four examples against a local TLS server that requires a
full client certificate chain
- document explicit mTLS endpoint selection, separate server trust,
transport-wide certificate scoping, rotation, and non-goals

## Why

Python already supports client certificates through
`SSLContext.load_cert_chain()`, and both supported HTTP client
implementations accept that context through `verify=`. This provides a
small, language-native mTLS path without adding a new SDK API or runtime
dependency.

Because the SDK cannot infer that an arbitrary custom HTTP client is
configured for mTLS, callers select `https://mtls.api.openai.com/v1` (or
an EU/custom endpoint) explicitly. The examples dedicate the
certificate-bearing transport to that origin and disable redirects.

## User impact

Users can copy tested file-based PEM recipes for synchronous or
asynchronous API-key traffic with either HTTPX or HTTPX2. There are no
exported API, generated-client, dependency, or lockfile changes.

## Validation

- `rye run pytest -vv -n 0 tests/test_mtls_http_client.py` — 4 passed
- `./scripts/lint`
- `rye build`
- `rye run python scripts/utils/validate-httpx2-wheel.py`
- `./scripts/test` — 7,083 passed, 29 skipped
- Pydantic v1 — 7,069 passed, 43 skipped
- thermo-nuclear code-quality review — no remaining blockers

## Scope

This does not add certificate-only X.509 workload identity, token
exchange, certificate refresh, or Realtime/WebSocket mTLS.
@pull pull Bot locked and limited conversation to collaborators Jul 31, 2026
@pull pull Bot added the ⤵️ pull label Jul 31, 2026
@pull
pull Bot merged commit 7a3d5e4 into gitupdates:main Jul 31, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants