-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Recognize byte slice for key argument in cluster client hash slot computation #3049
base: master
Are you sure you want to change the base?
Conversation
It seems that you have restricted modifications to your PR code. You can either open the permissions or resolve the conflicts yourself. |
e1f8ca8
to
7e90536
Compare
Done! Rebased and conflicts resolved |
@ofekshenawa merge? |
Is it possible to merge this? This PR fixes a pretty significant performance bug for us. Thanks! |
35ae45e
to
3cd7c33
Compare
@ofekshenawa I rebased this branch and the build is now green. Are we good to merge? Thanks. |
@vladvildanov @ofekshenawa Are you able to help with this merge? We have been running this patch in production for several months and have confirmed that it fixes the issue in the PR description. |
This PR is mildly related to #3048.
The cluster client uses the command type to determine the expected key position in the command arguments slice to compute the hash slot. This enables the client to properly send the command to the node that owns that slot, according to the cached cluster topology state.
For generic commands assembled with the
Do()
API, the logic falls back to assuming the key is at position 1. Though this is a reasonable assumption, it depends on the argument to be ofstring
type;[]byte
type arguments are not converted to strings, which results in an incorrect slot computation, thus forcing (in most cases) a double round trip caused by response to aMOVED
redirection.This PR adds a
[]byte
type case for key string serialization, so that the generic commands passed as byte slices yield the correct cluster hash slot.