Bump redis from 5.0.2 to 8.1.0 in /backend

[dependabot]

Bumps redis from 5.0.2 to 8.1.0.

Release notes

Sourced from redis's releases.

8.1.0

Changes

✨ Highlights

Async maintenance notifications

redis-py now supports server-pushed maintenance notifications in the asyncio stack for both standalone and cluster clients, bringing the async client to parity with the sync implementation. When a Redis deployment signals maintenance events (such as node migration or failover windows), the async client reacts through the maintenance-notifications handler (redis/maint_notifications.py and its async integration under redis/asyncio/), allowing applications to adapt connection handling during maintenance without downtime. (#4177)

Expanded command coverage

This release adds a batch of new command surfaces across core data types and modules:

• Lists — LMOVEM / BLMOVEM for moving multiple elements between lists (#4174).
• Sets — SDIFFCARD and SUNIONCARD cardinality commands (#4171).
• Streams — MAXCOUNT / MAXSIZE options for XREAD and XREADGROUP (#4173).
• Time Series — TS.READ (#4170), TS.QUERYLABELS (#4197), TS.NRANGE / TS.NREVRANGE (#4163), and an exclude_empty (EXCLUDEEMPTY) option for TS.MRANGE / TS.MREVRANGE (#4188).
• Search — FT.ALIASLIST (#4198) and a COLLECT reducer for aggregations (#4179).
• Sentinel — replica sentinel aliases (#4127).

🚀 New Features

• Add replica sentinel aliases (#4127)
• Add TS.NRANGE and TS.NREVRANGE support to the timeseries command surface (#4163)
• feat: add TS.READ command support to the timeseries module (#4170)
• feat: add SDIFFCARD and SUNIONCARD command support (#4171)
• feat: add MAXCOUNT/MAXSIZE support to XREAD and XREADGROUP (#4173)
• feat: add LMOVEM and BLMOVEM commands for moving multiple list elements (#4174)
• feat: add async maintenance-notifications support for standalone and cluster clients (#4177)
• feat: add COLLECT reducer support to search aggregations (#4179)
• feat: add exclude_empty (EXCLUDEEMPTY) option to TS.MRANGE and TS.MREVRANGE (#4188)
• feat: add TS.QUERYLABELS support to the timeseries command surface (#4197)
• feat: add FT.ALIASLIST support (#4198)

⚠️ Experimental

• feat: add client-side HIMPORT fieldset support for standalone and cluster clients (#4205)

The feature considered unstable and public API might be changed in the future minor version

🐛 Bug Fixes

• fix: detect closed pooled connection without consuming pending push data (RESP3 + hiredis) (#4156)
• Fix Sentinel pool capacity loss after failover (#4193)

... (truncated)

Commits

• e013126 Testing with 8.10 GA (#4227)
• 059d1e9 Fixed TS.NRANGE commands to correctly apply aggregators (#4225)
• d486a0a Fix FIELDNAME alias dropping first character of un-prefixed fields (#4224)
• fb93104 feat: add client-side HIMPORT fieldset support for standalone and cluster cli...
• 9197609 Fix lat/lon swap in search querystring geo() helper (#4223)
• 14714a0 fix: Fixed double decoding issue with unquote() (#4222)
• 227280a Update lib version to 8.1.0
• 88d16d0 Decode ACL LOG string values on the default RESP3 legacy callback (#4201)
• 599fd75 feat: add FT.ALIASLIST support (#4198)
• 71e275e test: add VectorField RERANK serialization tests for sync and async search (#...
• 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)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
pycon	Ready	Preview	Aug 20, 2026 2:22pm

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.08%. Comparing base (470187e) to head (83e10d8).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4808   +/-   ##
=======================================
  Coverage   93.08%   93.08%           
=======================================
  Files         356      356           
  Lines       11173    11173           
  Branches      902      902           
=======================================
  Hits        10400    10400           
  Misses        662      662           
  Partials      111      111           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[marcoacierno]

@claude update the lock file

[claude]

Claude finished @marcoacierno's task in 5m 47s —— View job

---

Lock file updated ✅

Pushed 736aad7 to dependabot/pip/backend/redis-8.1.0.

• Gather context (inspect PR diff & current lock state)
• Regenerate backend/uv.lock with uv lock
• Smoke-test the redis APIs the backend actually uses
• Run the backend test suite
• Commit and push

What changed

uv lock with uv 0.12.5 — the version pinned in backend/Dockerfile:32 and in the astral-sh/setup-uv steps of the CI workflows:

Resolved 236 packages in 1.06s
Removed async-timeout v5.0.1
Updated hiredis v3.0.0 -> v3.4.1
Updated redis v5.0.2 -> v8.1.0
Updated torch v2.12.1+cpu -> v2.12.1, v2.12.1+cpu

• async-timeout is gone: redis 8 no longer needs it on Python ≥ 3.11.
• torch is now two entries — 2.12.1 for sys_platform == 'darwin' and 2.12.1+cpu for everything else — both still from the pytorch-cpu index. grep -c 'name = "nvidia' uv.lock → 0, so the concern from Bump the uv group across 1 directory with 3 updates #4672 still holds.

⚠️ The diff is 1307/-1262 lines, but almost all of it is format churn. The committed lock predates the revision = 3 lockfile format, so uv 0.12.5 rewrote every entry to add upload-time metadata and collapsed the resolution-markers list. The only real resolution changes are the four lines above — grep -E '^[+-]version = ' over the diff returns exactly those.

Checks

Full backend suite, against live Postgres + Redis:

$ uv run pytest -n auto -q
1337 passed, 16 skipped, 3 xfailed, 673 warnings in 95.36s (0:01:35)

Since most tasks run eagerly in tests, I also exercised the redis paths directly against a live Redis with redis-py 8.1.0 — all passed:

• the lock API from pycon/celery_utils.py:56-61 — Redis.from_url → lock(timeout=…, thread_local=False) → acquire(blocking=False) / owned() / extend(…, replace_ttl=True) / release()
• llen("heavy_processing") from pycon/tasks.py:161
• a kombu redis-transport publish → consume → ack round trip (the Celery broker path)
• Celery's RedisBackend store/fetch of a task result

uv run mypy . and uv tool run ruff@0.12.5 check do report failures, but they are pre-existing on main and unrelated to this bump — mypy stops on missing django stubs and badge_scanner/models.py: Source file found twice under different module names, and ruff flags sponsors/tests/test_tasks.py:1:27: F401 unittest.mock.patch imported but unused. My only change is uv.lock, so none of these are caused by it. Neither tool runs in the backend CI workflows.

One thing worth a look before merging

kombu 5.6.2 declares its redis extra as redis!=4.5.5,!=5.0.2,<6.5,>=4.5.2. Nothing here declares celery[redis]/kombu[redis], so uv doesn't enforce that bound and my broker round trip worked fine — but redis-py 8.1.0 is above the range kombu says it supports, and the broker is redis in production. Worth knowing that's untested territory upstream rather than a validated combination. (Note the current pin, 5.0.2, is on kombu's exclusion list too, so this bump does move off a known-bad version.)

Also: because a non-dependabot commit now exists on this branch, Dependabot will no longer auto-rebase or recreate the PR.
• branch: dependabot/pip/backend/redis-8.1.0

[marcoacierno]

@claude fix the conflicts with main on uv.lock

[claude]

Claude finished @marcoacierno's task in 4m 33s —— View job

---

Conflicts resolved ✅

Pushed 83e10d8b to dependabot/pip/backend/redis-8.1.0 — a merge of main (470187e, "Remove the old pages system") into the branch.

• Gather context (fetch origin/main, inspect the conflict)
• Resolve backend/uv.lock against main
• Verify the lock is consistent (uv lock --check) and redis still resolves to 8.1.0
• Run backend tests
• Commit and push

How it was resolved

Only backend/uv.lock conflicted — backend/pyproject.toml auto-merged cleanly because the two bumps touch different lines (redis[hiredis]==8.1.0 on line 78, psycopg[c]==3.3.4 on line 106, the latter from #4806 which landed on main after this branch was cut).

For the lock I took main's version wholesale and re-ran uv lock (uv 0.12.5, the version pinned in backend/Dockerfile:32 and the CI workflows) to reapply the redis bump on top:

Resolved 236 packages in 1.07s
Removed async-timeout v5.0.1
Updated hiredis v3.0.0 -> v3.4.1
Updated redis v5.0.2 -> v8.1.0

uv lock --check then passes with no re-resolution needed.

The diff shrank a lot. My earlier commit 736aad7 was +1307/-1262 because the lock on this branch predated the revision = 3 format and uv rewrote every entry. Main's lock has since been regenerated in that same format by the psycopg PR, so that churn is now shared history rather than branch diff. The PR against main is:

 backend/pyproject.toml |  2 +-
 backend/uv.lock        | 70 ++++++++++++++++++++++++++++++++++++-------
 2 files changed, 52 insertions(+), 20 deletions(-)

git diff origin/main -- backend/uv.lock | grep -E '^[+-](name|version) = ' returns only async-timeout (removed — redis 8 doesn't need it on Python ≥ 3.11), hiredis 3.0.0 → 3.4.1, and redis 5.0.2 → 8.1.0. Nothing else moved; grep -c 'name = "nvidia' backend/uv.lock is still 0, and main's psycopg 3.3.4 resolution came through untouched.

Checks

Full backend suite on the merged tree, against live Postgres + Redis:

$ uv sync --frozen && uv run pytest -n auto -q
1340 passed, 15 skipped, 3 xfailed, 677 warnings in 89.56s (0:01:29)

And re-verified the redis APIs the backend actually calls, against a live server with redis-py 8.1.0 installed:

redis-py 8.1.0 | server 7.2.3
acquire True | owned True
llen heavy_processing 0

covering the lock path from pycon/celery_utils.py:56-61 (Redis.from_url → lock(timeout=…, thread_local=False) → acquire(blocking=False) / owned() / extend(…, replace_ttl=True) / release()) and llen("heavy_processing") from pycon/tasks.py:161.

I did not re-run mypy/ruff — this commit adds no Python changes of its own, and as noted earlier their failures are pre-existing on main and not run by the backend CI workflows.

Still worth a look before merging

Unchanged from my last comment: kombu 5.6.2 declares its redis extra as redis!=4.5.5,!=5.0.2,<6.5,>=4.5.2. Nothing here declares celery[redis]/kombu[redis], so uv doesn't enforce that bound — redis-py 8.1.0 sits above the range kombu claims to support, even though my broker round trip worked. Worth knowing it's untested upstream. (The current pin, 5.0.2, is on kombu's exclusion list, so this bump does move off a known-bad version.)

Also still true: with non-dependabot commits on the branch, Dependabot won't auto-rebase or recreate this PR.
• branch: dependabot/pip/backend/redis-8.1.0