Skip to content

Release 3.2.3: agentscore-py 2.8.2, fastapi 0.159.1, uv 0.13.5, pypi-publish v1.14.3 - #167

Merged
vvillait88 merged 2 commits into
mainfrom
sweep-2026-10-22
Oct 22, 2026
Merged

vvillait88 merged 2 commits into
mainfrom
sweep-2026-10-22

Conversation

@vvillait88

@vvillait88 vvillait88 commented Oct 22, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Release 3.2.3, from the 2026-10-22 maintenance sweep.

  • agentscore-py floor: >=2.8.1 to >=2.8.2, the SDK release from this sweep.
  • uv lock --upgrade:
    • fastapi 0.159.1
    • httpx2 and httpcore2 2.16.0
    • a2a-sdk 1.2.3
    • pydantic-settings 2.16.1
    • sentry-sdk 2.73.0
    • setuptools 84.2.1
    • bitarray 3.12.3
    • ty 0.0.90
    • python-dateutil 3.0.0, which arrives through cdp-sdk, whose range admits it
  • CI: setup-uv v10.3.2, uv 0.13.5 and pypi-publish v1.14.3.
  • aiohttp floored at >=3.14.4 in the mppx and aiohttp extras and the dev group.
    • pympp 0.14.0 exact-pins yarl==1.24.5 and propcache==0.5.2, and the only aiohttp compatible with those is 3.14.3, which has 8 advisories fixed in 3.14.4.
    • Our lock never showed this, because it resolves pympp 0.11.0. But a merchant's fresh pip install agentscore-commerce[mppx] could take the pympp 0.14 path.
    • Proof: forcing pympp==0.14.0 against the old manifest resolves aiohttp 3.14.3 (osv: 8 known vulnerabilities). With the floor, that combination is unsatisfiable, so pympp stays at 0.11 or lower, where it already was.
  • Held back: web3<8. pympp 0.14.0 (the latest) still requires eth-abi<6 for its tempo and stripe extras.
  • Prereleases: the only ones in the lock are OpenTelemetry's 0.66b1 semantic-conventions packages, which have never published a stable release. prerelease = "if-necessary" admits exactly those.

Worked with Varun.

Type of change

  • Bug fix (no breaking change)
  • New feature (no breaking change)
  • Breaking change (existing callers must update)
  • Docs, tests, or internal maintenance only

Public API

Unchanged.

Test plan

  • uv sync --frozen --all-extras --all-groups, then ruff check, ruff format, ty and vulture pass.
  • pytest: 1674 passed, 4 skipped.
  • osv-scanner on uv.lock: no issues found.

Checklist

  • Tests cover the new behavior, and the suite passes locally (no new behavior; the existing suite passes)
  • Lint, format, and type checks pass
  • Docs and README examples updated if the public surface changed (the public surface did not change)
  • No secrets, credentials, or personal data in the diff or the tests

@vvillait88

Copy link
Copy Markdown
Contributor Author

Review of 224a96d (read-only). One blocking finding, which predates this PR but ships in this release. Everything else checks out.

Blocking: a fresh agentscore-commerce[mppx] install resolves a vulnerable aiohttp, and CI tests a different pympp than merchants get

  • uv.lock holds pympp at 0.11.0 while PyPI's latest is 0.14.0 (uploaded 2026-10-13). Of the 26 direct, extra and dev requirements, pympp is the only one behind latest.
  • The cause: pympp 0.14.0's tempo and stripe extras exact-pin yarl==1.24.5 and propcache==0.5.2.
  • A merchant does not get our lock. uv pip compile of agentscore-commerce[mppx,fastapi]==3.2.2 on Python 3.13 resolves pympp 0.14.0, yarl 1.24.5 and aiohttp 3.14.3 (aiohttp arrives via web3). osv-scanner on that resolution reports the same 8 advisories.
  • 3.2.3 changes only the agentscore-py floor, so it would publish the same resolution. The 1674 tests also run against pympp 0.11.0, not the 0.14.0 a fresh install receives.
  • A one-line fix belongs in this release. Adding aiohttp>=3.14.4 to the mppx extra resolves a fresh install to aiohttp 3.14.5, yarl 1.25.1 and pympp 0.11.0: what the lock already carries, and what CI tests.
    • Capping the extra at pympp<0.12 has the same effect, but it is blunter.
    • Lift condition: a pympp release that drops the yarl/propcache exact pins, or moves them to versions aiohttp 3.14.4+ accepts.
  • Also record the hold with that lift condition. Correct the body as well: "pympp 0.14.0 still requires eth-abi<6" reads as though 0.14.0 is in the lock.

Lock diff, read in full (163 package names on both sides; the version line moves for exactly these)

  • a2a-sdk 1.2.3
  • agentscore-py 2.8.2
  • bitarray 3.12.3
  • fastapi 0.159.1
  • httpcore2 and httpx2 2.16.0
  • pydantic-settings 2.16.1
  • python-dateutil 3.0.0
  • sentry-sdk 2.73.0
  • setuptools 84.2.1
  • ty 0.0.90
  • the project itself at 3.2.3

No other package's dependency list changed, apart from python-dateutil gaining tzdata, which was already locked (2026.5). The lock's manifest still carries the web3<8 constraint.

python-dateutil 3.0.0

  • This is a real release: the GitHub release 3.0.0 is by the maintainer (2026-10-21T23:26Z), and both PyPI files carry provenance attestations.
  • Breaking items in NEWS:
    • tz.tzfile is rewritten on a zoneinfo backport, which changes gap-time offsets per PEP 495.
    • The bundled tz database is replaced by the tzdata dependency.
    • The mutable dateutil.tz.TZPATHS is removed, in favor of TZPATH / reset_tzpath.
    • dateutil.zoneinfo.rebuild and relative gettz keys now raise warnings as errors.
  • In the lock, only cdp-sdk depends on dateutil. Its 1.50.0 wheel has exactly one use, from dateutil.parser import parse, in cdp/openapi_client/api_client.py, and the parser is not on the breaking list.
  • agentscore_commerce/, tests/ and examples/ have no dateutil imports.

FastAPI 0.146 to 0.159.1

  • Release notes were read for 0.147.0 through 0.159.1. Every breaking item concerns request-parameter parsing:
    • omitted boolean form fields become False
    • defaults are no longer validated as input
    • empty form scalars and unselected files count as missing
    • JSON null is distinguished from an omitted body value
    • the deprecated **extra is removed from Path, Query, Header, Cookie, Body, Form and File
  • commerce's FastAPI gate takes only a starlette Request: AgentScoreGate.__call__(self, request) and the get_* dependencies. It imports no Query, Body, Form, Header, File or Path.
  • Its one private reach is ExceptionMiddleware._exception_handlers, which is starlette's. starlette is unchanged at 1.9.0 in both locks.

web3<8 hold, re-tested

  • pympp 0.14.0's requires_dist still carries eth-abi<6,>=5.0 on both the tempo and stripe extras, and web3 8.0.0 requires eth-abi>=6.
  • With the constraint removed in a scratch copy, uv lock --upgrade --dry-run moves web3 to 8.0.0b3, solana to 0.41.0 and websockets to 17.3. The constraint is still load-bearing.
  • With the constraint in place, the same dry run reports "No lockfile changes detected", so the lock is current under it.
  • The only prereleases in the lock are the three OpenTelemetry 0.66b1 packages.

CI inputs

  • setup-uv v10.3.2, uv 0.13.5 and pypi-publish v1.14.3 are each upstream's latest release.
  • GHSA-hq85-5cpj-mr62 (uv below 0.13.4, emSign root, critical) and GHSA-5xjx-3w67-w9x9 (pypi-publish, Sigstore chain CA revocation, critical) match the body.

Release and checks

  • 3.2.3 is unpublished: PyPI's latest is 3.2.2, and releases has no 3.2.3. The latest tag is v3.2.2.
  • gh pr checks 167: 12 rows, all pass. They are Analyze x3, CodeQL, Dependency Scan, Python Audit, ci, and test on Python 3.11 through 3.15.
  • osv-scanner 2.7.0 on the lock:
    • Base 89718f5: 164 packages, no issues.
    • Head 224a96d: 164 packages, no issues.
    • The forced pympp 0.14.0 lock is the positive control: 8 advisories, as above.

@vvillait88

Copy link
Copy Markdown
Contributor Author

Fixed in the new commit. aiohttp is floored at 3.14.4 in the mppx and aiohttp extras and the dev group. Forcing pympp==0.14.0 against the old manifest resolves aiohttp 3.14.3 (osv: 8 known vulnerabilities); with the floor, that combination is unsatisfiable (pympp[tempo] 0.14 pins yarl 1.24.5, every aiohttp at 3.14.4 or later needs yarl 1.25.1 or later), so fresh installs keep pympp at 0.11 or lower, matching the lock. The pympp hold and its lift condition go into the holds registry in this sweep's hivemind PR. The eth-abi line is corrected.

@vvillait88
vvillait88 merged commit ea8f1c3 into main Oct 22, 2026
12 checks passed
@vvillait88
vvillait88 deleted the sweep-2026-10-22 branch October 22, 2026 11:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant