sort Command lookupKeyRead and lookupKeyWrite are used on the opposite (#8283)

This is a recent problem, introduced by 7471743 (redis 6.0)

The implications are:
The sole difference between LookupKeyRead and LookupKeyWrite is for command
executed on a replica, which are not received from its master client. (for the master,
and for the master client on the replica, these two functions behave the same)!

Since SORT is a write command, this bug only implicates a writable-replica.
And these are its implications:

- SORT STORE will behave as it did before the above mentioned commit (like before
  redis 6.0). on a writable-replica an already logically expired the key would have
  appeared missing. (store dest key would be deleted, instead of being populated
  with the data from the already logically expired key)
- SORT (the non store variant, which in theory could have been executed on
  read-only-replica if it weren't for the write flag), will (in redis 6.0) have a new bug
  and return the data from the already logically expired key instead of empty response.

1 files changed, 1 insertions, 1 deletions

diff --git a/src/sort.c b/src/sort.c
index 44637720b..3b67cc639 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -270,7 +270,7 @@ void sortCommand(client *c) {
     }
 
     /* Lookup the key to sort. It must be of the right types */
-    if (storekey)
+    if (!storekey)
         sortval = lookupKeyRead(c->db,c->argv[1]);
     else
         sortval = lookupKeyWrite(c->db,c->argv[1]);