chore(deps): bump redis from 7.1.0 to 8.0.1

[dependabot]

Bumps redis from 7.1.0 to 8.0.1.

Release notes

Sourced from redis's releases.

8.0.1

Changes

🐛 Bug Fixes

• Fix Unix socket maintenance notification handling and tests (#4097)
• Fix async cluster node connection release on write errors (#4111)
• Fixed async MultiDBClient with underlying RedisCluster (#4108)
• Fix hiredis readiness checks for high file descriptors (#4115)
• fix(search): parse RESP3 FT.SEARCH responses with bytes-typed keys (#4109)
• Fixing pubsub's listen method to be blocking. (#4119)
• fix(asyncio): release pooled connection when Pipeline.reset() is cancelled (#4123)
• Avoid per-check fd allocation in hiredis _socket_can_read() — use poll() instead of a per-call selector (#4118)

🧰 Maintenance

• Updating PyJWT dependency. (#4100)
• Update CI badge in README.md (#4099)
• Add missing url query argument parser for ssl_min_version (#4047)
• ci: least-privilege permissions on spellcheck (read) and stale-issues (job-level write for actions/stale) (#4080)
• Bumping github-versions actions (#4102)
• Updating lib version + supported Redis versions in README.md + updating the Redis versions in CI test matrix (#4092)

We'd like to thank all the contributors who worked on this release! @​violuke @​mokashang @​arpitjain099 @​coredumperror @​elena-kolevska @​vladvildanov @​petyaslavova

8.0.0

Changes

🚀 Highlights

Async Cluster PubSub

This release introduces full asyncio Cluster PubSub support, bringing shard-channel capabilities (SSUBSCRIBE, SUNSUBSCRIBE, SPUBLISH) to the async RedisCluster client. The new ClusterPubSub class in redis.asyncio.cluster automatically routes shard-channel subscriptions to the correct cluster node based on key-slot hashing, manages per-node PubSub connections, and supports round-robin message retrieval across nodes. Users can create a cluster pubsub instance via RedisCluster.pubsub() and use ssubscribe(), sunsubscribe(), and get_sharded_message() just as they would with the sync cluster client.

Keyspace and subkey notifications

Redis Keyspace Notifications are now supported for standalone and cluster deployments in both sync and async modes. New classes — KeyspaceNotifications, ClusterKeyspaceNotifications, AsyncKeyspaceNotifications, and AsyncClusterKeyspaceNotifications — provide a high-level API for keyspace/keyevent subscriptions and subkey notification families: subkeyspace, subkeyevent, subkeyspaceitem, and subkeyspaceevent. Convenience methods like subscribe_keyspace(), subscribe_keyevent(), subscribe_subkeyspace(), subscribe_subkeyevent(), subscribe_subkeyspaceitem(), and subscribe_subkeyspaceevent() simplify common patterns, with channel classes for both key and subkey channels.

In cluster mode, subscriptions are managed across primary nodes because each node emits notifications only for keys it owns, with built-in topology-change handling. Sync run_in_thread() and async listen() workflows are supported.

Redis Array commands(https://redis.io/docs/latest/develop/data-types/arrays/)

redis-py now supports Redis Arrays, a preview Redis data type for sparse, index-addressable sequences of strings. New AR* command helpers cover indexed reads/writes, range scans, deletion, cursor-based insertion, ring-buffer writes, metadata, text search, and aggregation, including ARGET, ARSET, ARMGET, ARMSET, ARSCAN, ARGREP, ARRING, and AROP.

Type Hints Improvements (breaking changes)

The @overload pattern has been applied systematically across core commands (core.py), VectorSet commands, and module commands (Search, JSON, TimeSeries, Bloom filters) to provide distinct return types for sync and async clients. Previously, methods returned a combined ResponseT (i.e., Union[Awaitable[Any], Any]), which caused static analysis tools like mypy and Pyright to flag false positives. Now, sync clients see concrete return types (e.g., int, bool, list[str]) while async clients see Awaitable[...] wrappers. This is a breaking change for type-checking only—runtime behavior is unchanged, but code relying on the old union return types in type annotations may need updates. Two new protocol types, SyncClientProtocol and AsyncClientProtocol, are used in overload signatures to enable this distinction.

RESP3 by default with opt-in unified responses

... (truncated)

Commits

• 7c0fd11 Updating lib version to 8.0.1
• b7a4d7d Avoid per-check fd allocation in hiredis _socket_can_read() — use poll() ...
• eec778e fix(asyncio): release pooled connection when Pipeline.reset() is cancelled (#...
• 08e01bb Fixing pubsub's listen method to be blocking. (#4119)
• 3d5257a fix(search): parse RESP3 FT.SEARCH responses with bytes-typed keys (#4109)
• cce28ff Fix hiredis readiness checks for high file descriptors (#4115)
• e20691c Fixed async MultiDBClient with underlying RedisCluster (#4108)
• ea37fcc Fix async cluster node connection release on write errors (#4111)
• f4146fa Updating lib version + supported Redis versions in README.md + updating the R...
• d47674e Bumping github-versions actions (#4102)
• 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)

[rtibblesbot]

Dependabot bump of redis (production, via django-redis cache backend and Celery broker/backend) 7.1.0 → 8.0.1 — major version jump (7.x → 8.x, patched to 8.0.1).

• Breaking changes in 8.0.0: RESP3 becomes the default wire protocol (response shapes stay legacy-compatible unless legacy_responses=False); connection defaults change (socket_timeout/socket_connect_timeout now 5s instead of unset, keepalive on by default, max_connections defaults to 100, retries default to 10 with jitter backoff); type-hint-only @overload changes; new keyspace-notification classes (additive, unused here).
• 8.0.1: bug-fix only (pubsub blocking fix, async cluster/pipeline connection-release fixes, hiredis fd handling) — no new breaking changes.
• Compatibility: project only touches redis-py through django_redis.client.DefaultClient (contentcuration/contentcuration/utils/cache.py) using basic hget/hset/hdel — none of the changed APIs (async/cluster/pubsub/keyspace-notifications) are used directly. No code changes required.
• Peer dependencies: none affected; django-redis version unchanged. Unrelated resolver side-effect: google-api-core/googleapis-common-protos lose the [grpc] extra marker in the lockfile, but grpcio/grpcio-status remain pinned — not a functional removal.
• CI: passing.

One non-blocking item flagged inline on the new socket-timeout defaults.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

Ran a dependency-update review pipeline over the version bump:

• Classified the bump by semver (patch / minor / major) and dependency type (production vs. development)
• Extracted the changelog and release notes across the version range
• Assessed compatibility with this project's usage and whether any code changes are required
• Treated CI as the primary safety net
• Scaled the review depth to the update's risk
• Chose the verdict from semver risk, changelog findings, and CI status

[rtibblesbot]

suggestion: redis-py 8.0.0 changes client defaults so socket_timeout/socket_connect_timeout are now 5s instead of unset (blocking indefinitely). CACHES["default"]["OPTIONS"] in contentcuration/contentcuration/settings.py doesn't override these. CI won't surface this (local/fast Redis), but under real network latency or a loaded Redis instance, a call that previously blocked could now raise TimeoutError after 5s. utils/cache.py already wraps calls with retry/exception handling, so this is likely tolerated gracefully — worth a quick confirmation.

[rtibbles]

No concerns from changelog, no regressions observed in local test.