Hi Salvatore,
127.0.0.1:6379> xadd test1s3 * payload "{\"value\":9}"
1535405785383-0
127.0.0.1:6379> xadd test1s3 * payload "{\"value\":10}"
1535407105239-0
1535407105240-0
Did the second XADD call worked correctly? Why did it return two IDs (and appended the same value twice indeed)? What are the guarantees for the XADD command? Didn't find anything related in docs.
If this is a bug, I cannot suggest any other steps to reproduce besides the above, unfortunately. This behavior appears sporadically.
OS: Elementary (Ubuntu based) Redis version: 5.0-RC4 (though the server shows 4.9.104), just default standalone configuration, NO cluster, etc.
Regards, Denis
Comment From: antirez
No way this should ever happen... Does not make any sense especially since, even if there was a protocol error here, the second xadd should just read a reply and now two. Any idea about what were the conditions causing this?
Comment From: brotherdetjr
Hi,
Sorry for the delay. Unfortunately, I cannot tell any reproducible steps. Moreover, I've just tried to reproduce the bug, run xadd ~100 times in different combinations, and it seems gone. However I faced this bug too many times to consider it negligible. What I can tell, the entry was indeed added twice. In addition, there were some periods, when the duplication was occurring too often - approx. every 15th xadd.
Regards, Denis
Comment From: brotherdetjr
Hey, it seems, I've found the steps to reproduce!
1. start redis-server with default settings
2. start redis-cli
3. stop redis-server with ctrl+c
4. start redis-server again
5. issue an xadd command in redis-cli, e.g. xadd test1 * key1 value1
So the issue is somewhere around starting/stopping redis-server.
Wish you luck in satisfying "the word police" and get back to your normal development soon.
Thanks, Denis
Comment From: itamarhaber
Reproducible, and looks like a bug in the cli as INFO and MONITOR show that XADD was indeed run twice. I also found out that it happens with PING, possibly with other commands - should be a simple fix (I hope :)) /cc @artix75
Comment From: antirez
Yep indeed it looks like it's the reconnection code of redis-cli that was recently modified... Fixing ASAP.
Comment From: JingchengLi
Hello @antirez @itamarhaber ,
I have found the cause which introduce this bug, my initial commit move the re-connect codes about cluster-redirect responses into cliSendCommand to fix repeat argument issue，but i used a wrong condition about break statement in the while loop. acctually, the while loop is not needed after the re-connect codes moved. I have reproduced the issue as @brotherdetjr provided, I'm sure this new commit will fix the issue. Thanks!
Comment From: yoav-steinberg
This seems to have been resolved in #8930. I'm closing.