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.
Alongside this, Redis Keyspace Notifications are now supported for both standalone and cluster deployments, in both sync and async modes. New classes—KeyspaceNotifications, ClusterKeyspaceNotifications, AsyncKeyspaceNotifications, and AsyncClusterKeyspaceNotifications—provide a high-level API for subscribing to keyspace and keyevent channels. In cluster mode, notifications are automatically subscribed across all primary nodes (since each node only emits notifications for keys it owns), with built-in topology-change handling. Convenience methods like subscribe_keyspace(), subscribe_keyevent(), and channel classes (KeyspaceChannel, KeyeventChannel) simplify common subscription patterns. Both sync run_in_thread() and async listen() workflows are supported.
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.
We'd like to thank all the contributors who worked on this release! @abersheeran @alisaifee @majiayu000 @dmaier-redislabs @vladvildanov @petyaslavova
Fetched May 1, 2026