build(deps): bump aiohttp from 3.14.1 to 3.14.3

[dependabot]

Bumps aiohttp from 3.14.1 to 3.14.3.

[openai-sdks]

OkTest Summary

❌ Failed for Python SDK PR #3576.

View OkTest run #31555292815

_{SDK merge (f7c87559749a) · head (f0675154d472) · base (8bb0e14e58b5) · OkTest (91635c6a2723)}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0c6a930256

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Update the Rye lockfiles too

Given the documented Rye/pip setup paths, this bump only affects uv-based installs: both requirements.lock:15 and requirements-dev.lock:15 still pin aiohttp==3.14.1, while contributor setup and CI install through rye sync --all-features or pip install -r requirements-dev.lock (CONTRIBUTING.md:19, CONTRIBUTING.md:37, .github/workflows/ci.yml:47). In those environments the PR will continue installing and testing the old aiohttp version, so the dependency update does not actually take effect unless the Rye lockfiles are regenerated as well.

Useful? React with 👍 / 👎.

[jbeckwith-oai]

[P2] Raise the shipped aiohttp floor to the patched release

This change updates only uv.lock. The published aiohttp extra still allows aiohttp>=3.14.1, and requirements.lock / requirements-dev.lock (which Rye-backed CI installs) still resolve 3.14.1. GHSA-cq5v-8q36-5273 affects aiohttp <=3.14.2 and is fixed in 3.14.3; a malformed server response can trigger an out-of-bounds heap read and client DoS. Please raise the optional-dependency floor to >=3.14.3, update the two hard-coded validation expectations, and regenerate all relevant lockfiles so both downstream users and CI use the patched release.

[P1] Preserve the release-please marker

The lock refresh removes # x-release-please-version from the root openai package version. uv.lock is configured as a release-please extra-file, and that marker is what lets the generic updater find the version. Restore the comment so future release PRs continue updating the lockfile version.

Everything else checked out: the 119 locked aiohttp artifacts exactly match PyPI, supported Python/platform coverage is complete, aiohttp 3.14.3 is compatible with the SDK adapter in targeted tests and a live local request smoke test, and the release has had an 11-day cooling-off period.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d6046b2ba1

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Preserve the release-please marker

Removing # x-release-please-version here breaks the release automation path I checked: .github/workflows/create-releases.yml runs Release Please with release-please-config.json, and that config lists uv.lock under extra-files. Since uv.lock is not a TOML file that Release Please can target by a configured jsonpath, the inline marker is what tells the generic updater which version to rewrite; without it, the next automated release PR can update src/openai/_version.py while leaving the editable openai package entry in uv.lock stale.

Useful? React with 👍 / 👎.

[jbeckwith-oai]

[P1] Restore the Release Please version locator in uv.lock. This refresh removes # x-release-please-version from the root openai package at line 962, while release-please-config.json registers uv.lock as a generic extra-file. The generic updater only replaces annotated lines, so a future release can leave the lockfile project version stale. Restore the marker and ensure lock regeneration preserves it.

[P2] Complete the aiohttp security update across the published and tested dependency surfaces. Only uv.lock moves to 3.14.3; pyproject.toml still publishes aiohttp>=3.14.1, both Rye lockfiles still pin 3.14.1, and the policy/wheel validators still require that old floor. GHSA-cq5v-8q36-5273 affects aiohttp <=3.14.2 and is fixed in 3.14.3; exact-head CI also installed 3.14.1 through Rye. Raise the optional-dependency floor to >=3.14.3, update the two validation expectations, and regenerate uv.lock, requirements.lock, and requirements-dev.lock while preserving the release marker.

[jbeckwith-oai]

Requesting changes on exact head 2f20b81f42261ca00fd54875153bf51a4197b7bf.

1. High — preserve the Release Please version locator. uv.lock:912 drops # x-release-please-version from the root openai package version. release-please-config.json explicitly registers uv.lock as a generic extra-file, and repository history added this marker so future release PRs can update the locked project version. Please restore the marker after regenerating the lock.

2. Medium — complete the aiohttp security update across published and tested dependency surfaces. GHSA-cq5v-8q36-5273 affects aiohttp <=3.14.2 and is fixed in 3.14.3, but exact head only updates uv's resolved artifact. The published extra remains aiohttp>=3.14.1 at pyproject.toml:46 / uv.lock:951; both Rye locks still install 3.14.1 at requirements.lock:15 and requirements-dev.lock:15; and the policy and wheel validator canonize that vulnerable floor. Exact CI confirmed Rye installed 3.14.1. Please raise the declared floor and both validator expectations to >=3.14.3, regenerate uv.lock, requirements.lock, and requirements-dev.lock, and retain the Release Please marker.

Artifact provenance otherwise checks out: all 119 aiohttp 3.14.3 artifacts/hashes match official PyPI; Python/platform compatibility, diff hygiene, and file sizes are sound. Core build/lint/Python 3.10/3.14/HTTPX2/CodeQL checks pass. The examples secret failure and inherited Agents HTTPX2 errors are unrelated to this lock-only delta, though exact-head CI is not fully green.

[jbeckwith-oai]

Re-reviewed exact head f0675154d472f9c8fb8f4171ef320fdbec252270 after the dependency branch refresh. Both blockers remain:

1. High — preserve the Release Please locator. uv.lock:912 still removes # x-release-please-version from the root openai package version. Because release-please-config.json registers uv.lock as a generic extra-file, restore the marker so future release PRs continue updating the locked project version.

2. High — complete the aiohttp security update across published and exercised surfaces. aiohttp 3.14.3 fixes GHSA-cq5v-8q36-5273, but the published extra still permits 3.14.1 at pyproject.toml:46, both Rye locks still pin 3.14.1 at requirements.lock:15 and requirements-dev.lock:15, and the policy and wheel validator still canonize that vulnerable floor. Raise these to aiohttp>=3.14.3, regenerate uv.lock, requirements.lock, and requirements-dev.lock, and preserve the Release Please marker.

The artifact-only diff remains otherwise clean; all 119 wheels plus the sdist are represented. Current Rye setup and credential-less example failures are unrelated to this lock delta.