In #9812 we remove EVAL script verbatim replication, and no longer sort the redis command reply array.

It can work well in 7.0 and future versions, but we overlooked a potential data inconsistency problem, that is the old version (like 2.8/4.0) may still use verbatim replication in EVAL, and we doesn't sort the reply array now, eventually lead to inconsistency when upgrading from old version to 7.0, for a instance:

  1. start a 4.0 server, and a 7.0 server replicaof 4.0 server
  2. send mset a b c d e f to 4.0
  3. send eval "local res = redis.call('keys','*') redis.call('set','newkey',res[1])" 0 to 4.0
  4. using get newkey on 4.0, the result is a
  5. on 7.0 (the replica server), may get a random result

Start from old version's AOF (contain EVAL) also has this problem.

I don't see we mentioned the details in release note, even if we said it's a breaking change users still cannot handle it in a proper way, so I think we should fix it and there are two method: 1. just revert the sort part 2. sort the reply if the client is master or AOF

ping @redis/core-team , need your suggestions.

Comment From: oranagra

i have no concrete decision but i wanna point out that: 1. running that script directly on redis 7 also produces random result. actually that's true for 5.0 since effects replication was the default, and we didn't do sorting in that mode. 2. so it means we never intended to sort the output for the user in order to avoid random results, only in order to avoid inconsistency between the master and the replica (and when recovering from AOF) 3. if we'll solve it by re-introducing the sorting code into redis, we'll never be able to get rid of it (redis 9 may still need to read redis 4 AOF files)

Comment From: soloestoy

actually that's true for 5.0 since effects replication was the default, and we didn't do sorting in that mode.

yes, and seems no one met the issue till now, maybe I worried too much it's not a real problem, we can just do nothing, I don't wanna make the sort part in redis neither.

Comment From: oranagra

for the record, we realized this consistency problem exists since redis 5.0, since the replica does sorting according to it's local config, regardless of the fact the command came from the master.

if we do wanna provide upgrade path from 4.0 to 7.0, it would be better to make a new release of 4.0 (or 6.2) that handles that, instead of re-introducing the sorting code into 7.0 codebase.