chore: replace yanked multidict - #251
Merged
Merged
Conversation
multidict 6.3.2 was yanked from PyPI for a memory leak, but a yanked version stays installable when it is pinned exactly -- which a lockfile does. It survived because multidict is a transitive dependency of aiohttp and yarl and therefore never appears in pyproject.toml, so Dependabot as the pip ecosystem never looked at it. Nothing was holding it back: it moves to 6.7.1 on its own. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F3ADPwk11GHQF7BBwQHaPz
goloroden
force-pushed
the
chore/replace-yanked-multidict
branch
from
August 1, 2026 09:27
0f866d0 to
a5fdb1b
Compare
goloroden
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why multidict stayed on a yanked version
multidict 6.3.2was yanked from PyPI over a memory leak. A yanked release is skipped when a resolver picks versions freshly, but it stays installable when requested exactly — and a lockfile does exactly that.It survived for one reason:
multidictis a transitive dependency ofaiohttpandyarland never appears inpyproject.toml. Dependabot, running as thepipecosystem until #248, only ever looked at that file. Everything reachable only through the lockfile was therefore unmaintained — the yank just happened to be the one that produced a visible warning.Nothing was blocking the upgrade:
multidictmoves to 6.7.1 on its own, no constraint in the way.Scope
This affects the development and CI environment only. The published wheel declares
aiohttp==3.14.xand leavesmultidictto the consumer's resolver — which, being a fresh resolution, was skipping the yanked version all along. No user of the library was exposed to the leak.All 77 tests pass.
Note on detecting future yanks
This PR deliberately does not add an automated yank check. Two approaches were tried and both fail:
uv lock --checkdoes not read yank metadata at all when the lockfile is considered valid — verified against CI runs that hadmultidict 6.3.2locked and a cold cache, where no warning appeared.uv lock --check --refreshdoes surface the warning, but breaks the check itself: refreshing discards the metadata cache, and since the lockfile records complete wheel lists, any newly uploaded wheel for any dependency makes it report the lockfile as outdated even when no version changed. That would turn every future PR red at random.A periodic
uv lock --upgraderun is the more promising route — a fresh resolution skips yanked versions by construction, so it prevents the situation instead of detecting it. Tracked separately.🤖 Generated with Claude Code
https://claude.ai/code/session_01F3ADPwk11GHQF7BBwQHaPz