Note

Medium Risk
Changes sharded Pub/Sub connection lifecycle and retry/health logic in ClusterSubscriberGroup/ShardedSubscriber, which can affect subscription reliability and reconnect behavior under topology changes or failures.

Overview
Sharded Pub/Sub subscribers now start lazily and more safely. ClusterSubscriberGroup only starts a ShardedSubscriber when it owns slots with active channel subscriptions (or when redisOptions.lazyConnect is disabled), and can also trigger a start on-demand when a slot is first used.

Subscriber lifecycle/health handling was tightened. ShardedSubscriber now tracks explicit status (idle/starting/connected/...), dedupes concurrent start() calls, prevents revival after stop(), and reset() logic now replaces unhealthy subscribers and avoids resubscribe attempts when the underlying redis instance is missing/ended.

Config + test coverage expanded. The sharded subscriber now inherits ClusterOptions.redisOptions, and tests add coverage for default laziness, honoring redisOptions.lazyConnect, in-flight start behavior, and replace the single sharded pubsub scenario suite with split E2E suites plus a richer fault-injector client (create/delete DB, more action types) and test utilities (waitForAssertion, stricter message stats access).

^{Written by Cursor Bugbot for commit 5163b9b. This will update automatically on new commits. Configure here.}