Skip to content

fix(sentinel): propagate RESP option to clients #3011

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 7, 2025

Conversation

nkaradzhov
Copy link
Collaborator

createSentinel takes RESP as an option, but does not propagate down to the actual clients. This creates confusion for the users as they expect the option to be set to all clients, which is reasonable.

In case of clientSideCaching, this problem manifests as validation failure because clientSideCaching requires RESP3, but if we dont propagate, clients start with the default RESP2

fixes #3010

Description

Describe your pull request here


Checklist

  • Does npm test pass with this change (including linting)?
  • Is the new or changed code fully tested?
  • Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

`createSentinel` takes RESP as an option, but does not propagate down
to the actual clients. This creates confusion for the users as they
expect the option to be set to all clients, which is reasonable.

In case of clientSideCaching, this problem manifests as validation failure
because clientSideCaching requires RESP3, but if we dont propagate,
clients start with the default RESP2

fixes redis#3010
@nkaradzhov nkaradzhov merged commit 79749f2 into redis:master Jul 7, 2025
14 checks passed
@nkaradzhov nkaradzhov deleted the sentinel-csc-cannot-connect branch July 7, 2025 08:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

createSentinel with clientSideCache fail to connect() due to RESP version
3 participants