fix(cluster): Cluster reconnect sharded subscribers#2060
Merged
PavelPashov merged 2 commits intoredis:mainfrom Jan 15, 2026
Merged
fix(cluster): Cluster reconnect sharded subscribers#2060PavelPashov merged 2 commits intoredis:mainfrom
PavelPashov merged 2 commits intoredis:mainfrom
Conversation
PavelPashov
force-pushed
the
feat/cluster-reconnect-on-refresh-failure
branch
from
6b76f15 to
00f3d4b
Compare
❌ Security scan failedSecurity scan failed: Branch feat/cluster-reconnect-on-refresh-failure does not exist in the remote repository 💡 Need to bypass this check? Comment |
PavelPashov
changed the title
❌ Security scan failedSecurity scan failed: Branch feat/cluster-reconnect-on-refresh-failure does not exist in the remote repository 💡 Need to bypass this check? Comment |
When all sharded subscriber connections fail and the subsequent slots cache refresh returns ClusterAllFailedError, the cluster now properly enters reconnecting state instead of becoming zombied. This occurs when the cluster topology changes and all nodes are replaced with new IPs - the subscriber connections fail, triggering a slots refresh via the "-node" event handler. If this refresh fails (e.g., the duplicated connection for CLUSTER SLOTS times out or closes), the cluster becomes stuck in "ready" state with no working connections because normal pool connections use lazyConnect: true and never emit "end" events to trigger the drain->close->reconnect cycle. Now subscriber-triggered refreshSlotsCache() calls use a dedicated callback that detects ClusterAllFailedError and calls disconnect(true) to force reconnection, preventing the zombie state.
PavelPashov
force-pushed
the
feat/cluster-reconnect-on-refresh-failure
branch
from
aac0707 to
5e703f6
Compare
❌ Security scan failedSecurity scan failed: Branch feat/cluster-reconnect-on-refresh-failure does not exist in the remote repository 💡 Need to bypass this check? Comment |
PavelPashov
changed the title
nkaradzhov
approved these changes
Jan 15, 2026
github-actions bot
pushed a commit
that referenced
this pull request
Jan 15, 2026
## [5.9.2](v5.9.1...v5.9.2) (2026-01-15) ### Bug Fixes * **cluster:** Cluster reconnect sharded subscribers ([#2060](#2060)) ([def9804](def9804)) * preserve replica slots on MOVED in pipelines ([#2059](#2059)) ([a1c3e9d](a1c3e9d)) ### Reverts * Revert "fix: preserve replica slots on MOVED in pipelines (#2059)" (#2062) ([517b932](517b932)), closes [#2059](#2059) [#2062](#2062)
|
🎉 This PR is included in version 5.9.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
1 task
PavelPashov
added a commit
to PavelPashov/ioredis
that referenced
this pull request
Jan 15, 2026
* fix: trigger reconnect when sharded subscriber slots refresh fails When all sharded subscriber connections fail and the subsequent slots cache refresh returns ClusterAllFailedError, the cluster now properly enters reconnecting state instead of becoming zombied. This occurs when the cluster topology changes and all nodes are replaced with new IPs - the subscriber connections fail, triggering a slots refresh via the "-node" event handler. If this refresh fails (e.g., the duplicated connection for CLUSTER SLOTS times out or closes), the cluster becomes stuck in "ready" state with no working connections because normal pool connections use lazyConnect: true and never emit "end" events to trigger the drain->close->reconnect cycle. Now subscriber-triggered refreshSlotsCache() calls use a dedicated callback that detects ClusterAllFailedError and calls disconnect(true) to force reconnection, preventing the zombie state. * test: ensure reconnect after sharded subscriber failure
PavelPashov
added a commit
to PavelPashov/ioredis
that referenced
this pull request
Jan 15, 2026
* fix: trigger reconnect when sharded subscriber slots refresh fails When all sharded subscriber connections fail and the subsequent slots cache refresh returns ClusterAllFailedError, the cluster now properly enters reconnecting state instead of becoming zombied. This occurs when the cluster topology changes and all nodes are replaced with new IPs - the subscriber connections fail, triggering a slots refresh via the "-node" event handler. If this refresh fails (e.g., the duplicated connection for CLUSTER SLOTS times out or closes), the cluster becomes stuck in "ready" state with no working connections because normal pool connections use lazyConnect: true and never emit "end" events to trigger the drain->close->reconnect cycle. Now subscriber-triggered refreshSlotsCache() calls use a dedicated callback that detects ClusterAllFailedError and calls disconnect(true) to force reconnection, preventing the zombie state. * test: ensure reconnect after sharded subscriber failure
PavelPashov
added a commit
to PavelPashov/ioredis
that referenced
this pull request
Jan 15, 2026
* fix: trigger reconnect when sharded subscriber slots refresh fails When all sharded subscriber connections fail and the subsequent slots cache refresh returns ClusterAllFailedError, the cluster now properly enters reconnecting state instead of becoming zombied. This occurs when the cluster topology changes and all nodes are replaced with new IPs - the subscriber connections fail, triggering a slots refresh via the "-node" event handler. If this refresh fails (e.g., the duplicated connection for CLUSTER SLOTS times out or closes), the cluster becomes stuck in "ready" state with no working connections because normal pool connections use lazyConnect: true and never emit "end" events to trigger the drain->close->reconnect cycle. Now subscriber-triggered refreshSlotsCache() calls use a dedicated callback that detects ClusterAllFailedError and calls disconnect(true) to force reconnection, preventing the zombie state. * test: ensure reconnect after sharded subscriber failure
This was referenced Jan 15, 2026
This was referenced Feb 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When all sharded subscriber connections fail and the subsequent slots cache refresh returns
ClusterAllFailedError, the cluster now properly enters reconnecting state instead of becoming zombied. This occurs when the cluster topology changes and all nodes are replaced with new IPs - the subscriber connections fail, triggering a slots refresh via the-nodeevent handler. If this refresh fails (e.g., the duplicated connection forCLUSTER SLOTStimes out or closes), the cluster becomes stuck inreadystate with no working connections because normal pool connections use lazyConnect: true and never emitendevents to trigger the drain->close->reconnect cycle. Now subscriber-triggeredrefreshSlotsCache()calls use a dedicated callback that detectsClusterAllFailedErrorand callsdisconnect(true)to force reconnection, preventing the zombie state.