fix(cluster): reject commands before cluster topology is ready - #3321
Merged
nkaradzhov merged 2 commits intoJul 8, 2026
Merged
Conversation
RedisCluster commands issued before connect() resolves (or without calling connect() at all) crashed with "Cannot read properties of undefined (reading 'replicas')" instead of a clear error, because the slot map is only populated after the initial topology discovery completes. Track readiness separately from open/closed state and reject with ClientClosedError (never connected) or ClientOfflineError (connect in progress) before touching the slot map. Fixes redis#2704.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
Reviewed by Cursor Bugbot for commit 78799f8. Configure here.
connect() set #isReady = true unconditionally once discovery resolved, and didn't reset #isReady when starting a new session. If destroy() ran while discovery was still in flight, that in-flight discovery could later resolve successfully and mark the (already torn down) cluster ready again, or leak a stale true into a subsequent connect() attempt whose own discovery hasn't finished yet -- letting #assertReady() pass before the slot map is actually populated. Reset #isReady at the start of connect(), and only flip it back to true if the cluster is still open by the time discovery resolves.
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.
Description
Fixes #2704.
If a command is issued on a
RedisClusterclient beforeconnect()resolves (or without callingconnect()at all), it throws an unclearTypeError: Cannot read properties of undefined (reading 'replicas')instead of a helpful error. This happens because the slot map (this.slots) is only populated once the initial topology discovery finishes, and command routing (getClientAndSlotNumber,getClient,getPubSubClient,getShardedPubSubClient) accessed it unconditionally.This adds an
isReadyflag toRedisClusterSlots(exposed onRedisClusteralongside the existingisOpen), tracked independently ofisOpen:isOpen: true onceconnect()/.destroy()toggles it (existing behavior)isReady: true only after the initial topology discovery succeeds; reset on error/destroyA new
#assertReady()guard runs before slot map access in the four command-routing entry points, throwing:ClientClosedErrorif the client was never openedClientOfflineErrorif it's open but topology discovery hasn't completed yetisReadyis only touched by the initialconnect()/destroy()paths — it is not affected byrediscover()/#discover(), so live topology refresh and resharding are unaffected (verified by tracing all call sites).Testing
main(confirmed identical error message/stack to the issue) before writing the fix.Cluster command lifecycledescribe block covering both reported scenarios (never connected, andconnect()in flight but not awaited) — both fail with the originalTypeErroronmainand pass with this change. These don't require a running Redis server.cluster/index.spec.tssuite locally; the handful of unrelated failures (FUNCTION LOAD, genericClientsendCommand/multi tests) reproduce identically on unmodifiedmain, confirmed via a side-by-side baseline run — pre-existing local flakiness, not introduced by this change.npm run buildandeslinton the changed files are clean.Checklist
npm testpass with this change (including linting)? (see note above on pre-existing unrelated local flakiness)isReadyis a small additive public getter; happy to add a docs mention if maintainers want one.Note
Low Risk
Targeted lifecycle guard on cluster routing entry points;
isReadyis not tied to ongoingrediscover()so live topology refresh behavior stays unchanged.Overview
Cluster clients now expose
isReadyand reject command routing until initial topology discovery finishes, instead of crashing with aTypeErroron an empty slot map.RedisClusterSlotstracksisReadyseparately fromisOpen: open as soon asconnect()starts, ready only after the first successful discovery.#assertReady()runs before slot-based routing (getClientAndSlotNumber,getClientForKey, pub/sub client getters), throwingClientClosedErrorwhen never opened andClientOfflineErrorwhile discovery is still in flight.connect()only sets ready and emitsconnectif the cluster is still open after discovery (so a concurrentdestroy()cannot resurrect readiness);destroy()/#destroy()clear ready.RedisClusterforwards theisReadygetter. New unit tests cover commands before connect and during an in-progress connect without a live Redis.Reviewed by Cursor Bugbot for commit 7f6fc90. Bugbot is set up for automated code reviews on this repo. Configure here.