Redis Stream: Inconsistency between master and replica some XREADGROUP case

XREADGROUP auto-creates the consumer inside the consumer group the first time it saw it. When XREADGROUP is being used with NOACK option, the message will not be added into the client's PEL and XGROUP SETID would be propagated. When the replica gets the XGROUP SETID it will only update the last delivered id of the group, but will not create the consumer. This issue will also appear when loading from AOF.

For example: master:

127.0.0.1:6379> XGROUP CREATE s g $ MKSTREAM
OK
127.0.0.1:6379> XADD s * f v
"1587569636643-0"
127.0.0.1:6379> XREADGROUP GROUP g c1 NOACK STREAMS s >
1) 1) "s"
   2) 1) 1) "1587569636643-0"
         2) 1) "f"
            2) "v"
127.0.0.1:6379> XINFO CONSUMERS s g
1) 1) "name"
   2) "c1"
   3) "pending"
   4) (integer) 0
   5) "idle"
   6) (integer) 6863
127.0.0.1:6379> XINFO GROUPS s
1) 1) "name"
   2) "g"
   3) "consumers"
   4) (integer) 1
   5) "pending"
   6) (integer) 0
   7) "last-delivered-id"
   8) "1587569636643-0"

replica:

127.0.0.1:6380> XINFO CONSUMERS s g
(empty array)
127.0.0.1:6380> XINFO GROUPS s
1) 1) "name"
   2) "g"
   3) "consumers"
   4) (integer) 0
   5) "pending"
   6) (integer) 0
   7) "last-delivered-id"
   8) "1587569636643-0"

I thought about 2 available options: 1. Create new XGROUP subcommand -> XGROUP CREATECONSUMER. (And propagate it alongside XGROUP SETID) 2. XREADGROUP will not create the consumer if NOACK was specified.

I think that option 1 is more suited. @antirez what do you think? I can implement it and PR

Comment From: valentinogeron

@antirez - what do you think? I think that now with the new command XINFO STREAM FULL, it would be strange to get different responses from the master and its replica.

Comment From: oranagra

@antirez can you please take a look and advise?

Comment From: oranagra

i'm in favor of adding CREATECONSUMER too. first, because we do already have DELCONSUMER. i don't like the other option which changes the behavior on the master, i rather change the behavior on the replica. @guybe7 what do you think?

Comment From: guybe7

@oranagra yes, i think CREATECONSUMER is the better option... @valentinogeron care to implement?

Comment From: valentinogeron

@oranagra @guybe7 - I will submit a PR soon

Comment From: oranagra

I now realize that we can't probably put this into Redis 6.0.x since it affects the replication stream and AOF format in a non-backwards compatible way (older 6.0 servers wont understand the command).

Although it's worth noting that both AOF and replica don't really fail anything when run into an unrecognized command, and the inconsistency already existed in these versions anyway, so in that respect, it's not really a regression.

@guybe7 @valentinogeron please share your thoughts, and if you see any way to change #7526 to solve that?

Comment From: yossigo

@valentinogeron just to be sure I'm not missing something here, other than XINFO not showing accurate information about consumers does this introduce other consistency issues?

Comment From: valentinogeron

@yossigo - no