[dependabot]

Bumps multidict from 6.7.1 to 6.9.1.

Release notes

Sourced from multidict's releases.

6.9.1

Bug fixes

• Fixed the C extension reading freed memory on free-threaded builds when a list handed to :py:meth:~multidict.MultiDict.update, :py:meth:~multidict.MultiDict.extend, :py:meth:~multidict.MultiDict.merge or the :py:class:~multidict.MultiDict and :py:class:~multidict.CIMultiDict constructors, a [key, value] item inside any iterable handed to them, or a list tested with in against :py:meth:~multidict.MultiDict.items, is changed by another thread; a call that catches the list shrinking under it now raises :py:exc:RuntimeError -- by :user:rodrigobnogueira.

  Related issues and pull requests on GitHub: #1437.

• Fixed a data race on the free-threaded build where a retired hash table's reader count used relaxed atomics, letting a lock-free get()/getone()/ __getitem__() read race a concurrent free of that table. The reader-exit decrement and the drain's free check now use release/acquire ordering instead -- by :user:asvetlov.

  Related issues and pull requests on GitHub: #1481.

• Fixed a free-threaded build bug where two threads calling update(), merge(), or __setitem__() on the same key at the same time could lose the key entirely instead of just racing on which value wins. A decref of the replaced value could transiently suspend the writer's critical section, letting a second writer for the same key observe the first writer's in-progress entry as absent and, once both settled, mistake it for a stale duplicate and delete it. Every such decref is now deferred until the writer has released its critical section, so the window can no longer open. setdefault() had an unrelated instance of the same blind spot (it could insert a duplicate rather than recognizing an in-flight key), fixed alongside it -- by :user:asvetlov.

  Related issues and pull requests on GitHub: #1483.

• Fixed a free-threaded build bug where getall() and the items()/ keys()/values() equality path could raise KeyError or report a present, never-deleted key as missing. A concurrent update()/extend()/ __setitem__() call can have its critical section transiently suspended (a decref triggering a blocking allocator call) while an entry is marked as part of its own bookkeeping; a reader landing in that window used to treat the mark as "not found" instead of "still there, in flight" -- by :user:asvetlov.

  Related issues and pull requests on GitHub:

... (truncated)

Changelog

Sourced from multidict's changelog.

6.9.1

(2026-09-21)

Bug fixes

• Fixed the C extension reading freed memory on free-threaded builds when a list handed to :py:meth:~multidict.MultiDict.update, :py:meth:~multidict.MultiDict.extend, :py:meth:~multidict.MultiDict.merge or the :py:class:~multidict.MultiDict and :py:class:~multidict.CIMultiDict constructors, a [key, value] item inside any iterable handed to them, or a list tested with in against :py:meth:~multidict.MultiDict.items, is changed by another thread; a call that catches the list shrinking under it now raises :py:exc:RuntimeError -- by :user:rodrigobnogueira.

  Related issues and pull requests on GitHub: :issue:1437.

• Fixed a data race on the free-threaded build where a retired hash table's reader count used relaxed atomics, letting a lock-free get()/getone()/ __getitem__() read race a concurrent free of that table. The reader-exit decrement and the drain's free check now use release/acquire ordering instead -- by :user:asvetlov.

  Related issues and pull requests on GitHub: :issue:1481.

• Fixed a free-threaded build bug where two threads calling update(), merge(), or __setitem__() on the same key at the same time could lose the key entirely instead of just racing on which value wins. A decref of the replaced value could transiently suspend the writer's critical section, letting a second writer for the same key observe the first writer's in-progress entry as absent and, once both settled, mistake it for a stale duplicate and delete it. Every such decref is now deferred until the writer has released its critical section, so the window can no longer open. setdefault() had an unrelated instance of the same blind spot (it could insert a duplicate rather than recognizing an in-flight key), fixed alongside it -- by :user:asvetlov.

  Related issues and pull requests on GitHub: :issue:1483.

• Fixed a free-threaded build bug where getall() and the items()/ keys()/values() equality path could raise KeyError or report a present, never-deleted key as missing. A concurrent update()/extend()/ __setitem__() call can have its critical section transiently suspended (a decref triggering a blocking allocator call) while an entry is marked as

... (truncated)

Commits

• 0a1770c Release 6.9.1 (#1504)
• d220522 Upload release assets one at a time to avoid the secondary rate limit (#1503)
• 30cd596 Stop a GIL-releasing del from segfaulting the standard C extension build ...
• d1c331a Recheck the reader gate after taking the retired list (#1502)
• b37f07c Allocate deferred decrefs in fixed-size blocks (#1501)
• 563f667 Run CodSpeed benchmarks on Python 3.14 and loop the smallest ones (#1498)
• 157c87c Cancel superseded CI runs on pull requests (#1500)
• d43adfe Drop -I from the ASan test command so PYTHONMALLOC takes effect (#1499)
• 2a68472 Stop items() iteration from reading a freed entry in CIMultiDict (#1496)
• cd528d6 Rename GHSA-54p9-h82j-f925 changelog fragment to the merged commit (#1495)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

---

Summary by cubic

Updates multidict from 6.7.1 to 6.9.1. This release fixes memory safety and data race issues in free-threaded builds, improves concurrent mutation handling, and includes a security fix (GHSA-54p9-h82j-f925).

^{Written for commit da894b8. Summary will update on new commits.}

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Repository: JWEB0689/coderabbit/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: bbb70032-648b-49ed-b41a-8f6294dadabe

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[kilo-code-bot]

🔥 The Roast: This bump pulls in a memory-safety fix for multidict's C extension (the advisory referenced in the release notes, GHSA-54p9-h82j-f925, plus the items()-reads-freed-entry fix) — and fixes it the way a fire extinguisher fixes a kitchen fire: only inside this building. The lockfile now pins the patched release for our own Docker/CI builds, but multidict appears nowhere in [project].dependencies, so a pip install pr-agent still resolves it purely by transitively trusting aiohttp and yarl to land on a patched release. Meanwhile the policy comment right above dependencies in pyproject.toml says security-sensitive packages declare >=patched,<next-major precisely so pip consumers get security patches on their own cadence (The-PR-Agent#2523) — and there is literally a guard test (tests/unittest/test_certifi_pin_policy.py) that enforces that for certifi. multidict is the C-extension implementation behind the HTTP header maps that every aiohttp request and response flows through; "we'll just trust the resolver" is a bold stance to take on a use-after-free.

🩹 The Fix: Declare the vetted floor in pyproject.toml alongside the other security-sensitive ranges, and keep uv.lock as the exact pin for our own builds:

  "multidict>=6.9.1,<7",

Optionally add a test_multidict_pin_policy.py in the style of the certifi guard so the floor does not quietly drift back to a vulnerable release.

📏 Severity: suggestion

[kilo-code-bot]

Code Review Roast 🔥

Verdict: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
🚨 critical	0
⚠️ warning	0
💡 suggestion	1
🤏 nitpick	0

Issue Details (click to expand)

File	Line	Roast
uv.lock	1976	Lock-only bump of a security-fixed transitive dep: pip consumers get no declared floor on the patched multidict release, contradicting the repo's own security-pin policy (The-PR-Agent#2523)

---

🏆 Best part: The wheel matrix went from 101 entries to 140 without dropping a single platform — cp312/313/314 coverage intact, plus fresh cp315/cp315t, riscv64, and Android/iOS builds. Dependabot did the boring part flawlessly; I checked every tag and nothing fell off the list. Annoyingly responsible.

💀 Worst part: The fix is real (GHSA-54p9-h82j-f925 territory — use-after-free in the multidict C extension), but it lives only in uv.lock. multidict is not declared in [project].dependencies, so anyone doing pip install pr-agent inherits whatever version the resolver lands on. The pyproject policy comment says security-sensitive packages declare >=patched,<next-major so pip consumers get patches on their own cadence, and there's a guard test for certifi proving the team means it. The extinguisher is in the building; the smoke detector isn't.

📊 Overall: A textbook, cleanly-generated dependabot bump — right version, right hashes, no collateral damage. The only gap is the one the lockfile cannot fix by itself: the floor exists for Docker, and not for the people who pip install you.

Fix these issues in Kilo Cloud

Files Reviewed (1 files)

• uv.lock - 1 issue

Verification Notes

• multidict is absent from [project].dependencies in pyproject.toml; it enters the tree transitively via aiohttp and yarl (lock entries at uv.lock:60 and uv.lock:4079).
• Repo security-pin policy: pyproject.toml dependency comment referencing Relax exact == pins on transitive deps so consumers can pull security patches (GitPython, aiohttp, PyJWT, dynaconf, ujson, starlette/fastapi) The-PR-Agent/pr-agent#2523, enforced for certifi by tests/unittest/test_certifi_pin_policy.py.
• No source code imports multidict directly, so there is no application-level code change to review.
• uv lock --check (CI, .github/workflows/build-and-test.yaml:23) was not executed locally — this review is read-only, so lock freshness against pyproject.toml is unverified here.

---

_{Reviewed by free · Input: 88.7K · Output: 14K · Cached: 1.2M}