Skip to content

chore(deps): bump the uv group across 1 directory with 2 updates - #751

Merged
vishal-bala merged 1 commit into
mainfrom
dependabot/uv/uv-62281dbf52
Oct 26, 2026
Merged

chore(deps): bump the uv group across 1 directory with 2 updates#751
vishal-bala merged 1 commit into
mainfrom
dependabot/uv/uv-62281dbf52

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Oct 9, 2026 •
edited by cursor Bot
Loading

Copy link
Copy Markdown
Contributor

Bumps the uv group with 2 updates in the / directory: fsspec and multidict.

Updates fsspec from 2026.4.0 to 2026.6.0

Commits
  • a245700 changelog (#2049)
  • 652325d Fix async cat ranges on error (#2045)
  • 073aac8 Forward kwargs from cat_ranges to cat_file (#2044)
  • 2818611 FTP: preserve filenames containing whitespace in _mlsd2 (#2043)
  • c879384 Prevent attribute error by checking for 'forced' attribute before flushing ca...
  • 71b8a6b Reflect async _walk correctly (#2040)
  • 5eec9f9 Fix: Omit threading.get_ident() from cache token for async implementations ...
  • 8643878 Small safety improvements (#2039)
  • a1c16ab Honour simple_templates everywhere in referenceFS (#2029)
  • 85facaa Fix infinite recursion in expand_path when resolving paths with glob magic ch...
  • Additional commits viewable in compare view

Updates 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 <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
  • @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
  • @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
  • @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
  • @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions
    You can disable automated security fix PRs for this repo from the Security Alerts page.

Note

Low Risk
Lockfile-only transitive dependency bumps with no direct code changes; multidict updates harden aiohttp’s header handling under concurrency.

Overview
This PR only updates uv.lock as part of a Dependabot uv dependency-group bump—no pyproject.toml or application code changes.

It pins fsspec 2026.4.0 → 2026.6.0 (transitive, e.g. via huggingface_hub) and multidict 6.7.1 → 6.9.1 (transitive via aiohttp), including refreshed wheel/sdist hashes and an expanded multidict wheel matrix (e.g. RISC64, Android/iOS).

The multidict jump is mainly C-extension concurrency and memory-safety fixes (including free-threaded builds and standard-build segfault hardening); fsspec is a minor release with async/filesystem bug fixes per upstream.

Reviewed by Cursor Bugbot for commit b587958. Bugbot is set up for automated code reviews on this repo. Configure here.

@dependabot
chore(deps): bump the uv group across 1 directory with 2 updates
b587958 
Bumps the uv group with 2 updates in the / directory: [fsspec](https://github.com/fsspec/filesystem_spec) and [multidict](https://github.com/aio-libs/multidict).


Updates `fsspec` from 2026.4.0 to 2026.6.0
- [Commits](fsspec/filesystem_spec@2026.4.0...2026.6.0)

Updates `multidict` from 6.7.1 to 6.9.1
- [Release notes](https://github.com/aio-libs/multidict/releases)
- [Changelog](https://github.com/aio-libs/multidict/blob/master/CHANGES.rst)
- [Commits](aio-libs/multidict@v6.7.1...v6.9.1)

---
updated-dependencies:
- dependency-name: fsspec
  dependency-version: 2026.6.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: multidict
  dependency-version: 6.9.1
  dependency-type: indirect
  dependency-group: uv
...

Signed-off-by: dependabot[bot] <[email protected]>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file python:uv Pull requests that update python:uv code labels Oct 9, 2026
@vishal-bala
vishal-bala merged commit 33cf03d into main Oct 26, 2026
54 of 56 checks passed
@dependabot
dependabot Bot deleted the dependabot/uv/uv-62281dbf52 branch October 26, 2026 13:03
@vishal-bala vishal-bala mentioned this pull request Oct 30, 2026
Merged
vishal-bala added a commit that referenced this pull request Oct 30, 2026
@vishal-bala
fix(ci): route Dependabot PRs through the maintainer-dispatched servi…
28f663a 
…ce tests (#802)

## Motivation

Every Dependabot PR fails CI on two jobs, Service Tests and Notebook
Validation, regardless of what it bumps. Dependabot pushes its branches
to this repository, so its PRs pass the same-repository guard that keeps
fork PRs away from secret-dependent jobs. GitHub, however, gives runs
that Dependabot triggers no Actions secrets, so those jobs start with
every API key empty. On #751, Service Tests stops at the Google Cloud
authentication step for want of `GOOGLE_CREDENTIALS`, and the notebooks
fall through to `getpass` prompts that cannot run in CI. The same two
jobs failed on #744, #749, #751 and #799.

## Changes

This PR treats Dependabot PRs the way fork PRs are already treated: the
secret-dependent jobs skip, and a maintainer runs them with secrets
after reading the change.

- `.github/workflows/test.yml`: Service Tests and Notebook Validation
also skip when `github.actor` is `dependabot[bot]`. The guard keys on
the actor because that is what GitHub withholds secrets on, so a
maintainer's push to a Dependabot branch still runs both jobs with
secrets.
- `.github/workflows/test-fork-pr.yml`: the dispatch-only workflow now
accepts PRs opened by `dependabot[bot]` as well as fork PRs, and still
rejects other same-repository PRs.
- `CONTRIBUTING.md`: a short section telling maintainers to run `gh
workflow run test-fork-pr.yml -f pr_number=<n>` before merging a fork or
Dependabot PR.

## Notes

- A skipped job shows as passing, so the manual dispatch is a
convention, not an enforced gate. Copying the API keys into the
Dependabot secrets store would make the jobs run automatically, but it
would also hand those keys to newly bumped dependency code before anyone
has reviewed it, which defeats the purpose of waiting for a maintainer.
- The check run keeps the name "Fork PR - Service Tests" so that any
branch-protection rule or tooling referring to it keeps matching.
- Notebook Validation has no manual equivalent, as is already the case
for fork PRs. It still runs on `main` after merge and nightly.

## Reviewer Brief

**Start here:** `.github/workflows/test.yml:25`, the Service Tests `if:`
guard. It decides which PR runs get secret-dependent jobs, and the
Notebook Validation guard at `:152` repeats it.

**Where it could fail**
- `.github/workflows/test-fork-pr.yml:46-51`: the new acceptance checks
who opened the PR (`pr.data.user.login`), not who wrote its commits, so
a write-access user's commit on a Dependabot branch would also be tested
with secrets; that user can already run code with secrets from any
same-repository branch.

**Not verified:** neither workflow has run with this change. The
`github.actor` guard and the Dependabot acceptance in `test-fork-pr.yml`
can only be confirmed on a real Dependabot PR plus a manual dispatch.
actionlint was not available; both files parse as YAML, and the `setup`
script passes `node --check`.

**Beyond CI:** the logs of run 37937957172 (#751) show every secret
empty on a Dependabot-triggered run, Service Tests failing at Google
Cloud authentication, and Notebook Validation failing on `getpass`
API-key prompts, which confirms that both jobs need secrets and lose no
working coverage by skipping.

**Since the last brief:** `a59789b7` passes `GEMINI_API_KEY` to the
dispatched service tests, matching `test.yml`, so the Google GenAI
fixture exercises the Gemini backend there too.

<sub>Reviewed `d8a7d3a7` · Claude Code (claude-opus-5-5) · lenses:
correctness, security, design, tests, docs, Redis behaviour</sub>

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Workflow and contributor-doc changes only; no application or
secret-handling logic changes, though skipped jobs still report as
passing until a maintainer runs the dispatch workflow.
> 
> **Overview**
> Dependabot PRs were hitting **Service Tests** and **Notebook
Validation** with no Actions secrets (same-repo branches, but GitHub
withholds secrets on Dependabot-triggered runs), so CI failed on empty
API keys. This PR aligns Dependabot with the existing fork PR pattern.
> 
> **`test.yml`** skips those secret-dependent jobs when `github.actor`
is `dependabot[bot]` (while still running them for maintainer pushes on
the same branch). **`test-fork-pr.yml`** now allows manual dispatch for
Dependabot PRs as well as forks, with updated validation and comments.
**`CONTRIBUTING.md`** documents running `gh workflow run
test-fork-pr.yml -f pr_number=<n>` before merge.
> 
> The fork-pr workflow also wires **`GEMINI_API_KEY`** into the
service-tests env alongside the other provider secrets.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
a59789b. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
@vishal-bala vishal-bala added auto:dependencies Update one or more dependencies version released This issue/pull request has been released. and removed dependencies Pull requests that update a dependency file labels Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@vishal-bala vishal-bala vishal-bala approved these changes

Assignees

No one assigned

Labels

auto:dependencies Update one or more dependencies version python:uv Pull requests that update python:uv code released This issue/pull request has been released.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@vishal-bala