Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


SORT STORE on cluster works when it shouldn't #1580

mgravell opened this Issue · 3 comments

3 participants


SORT STORE is a multi-key command, so it probably shouldn't even work at all until beta 2, but more alarmingly: it works even when the target key is not on the server, for example - here "b" and "c" are on different nodes (as demonstrated in the first few lines).

Also, the "by" clause is also multi-key, so probably needs consideration.

get b
get c
(error) MOVED ...
lpush b x
(integer) 1
lpush b y
(integer) 2
lpush b z
(integer) 3
sort b alpha
1) "x"
2) "y"
3) "z"
sort b alpha store c
(integer 3)
keys c
1) "c"
get c
(error) MOVED ...

Which shows that we've successfully put the database into an inconsistent state

@antirez antirez added this to the Redis 3.0 milestone

The sort command currently doesn't have a way of returning the key used in the store subcommand. We need to implement a custom getkeys_proc function to enumerate the optional store key.


Yep... I'm fixing it today, however this means that I'll deny the "GET" option in SORT while in Cluster mode since we can't anticipate keys fetched, at least for now. It is actually possible to analyze the GET pattern and deny it only if it does not include an hash tag inside, then in the key extraction function return the pattern so that an error will be raised if it is not in the right hash slot.



@antirez antirez closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.