Redis updates the replication offset on commandProcessed function which are called right after the processCommand finished, assuming that this indicate that the command was also finished. In case of module that takes the execution to a background thread and blocks the client, this assumption is not true. This cause the master to think that the command execution was finished and the wait command to not wait until the command invocation was actually done.
Notice that this issue can only happened with modules, Redis will never block the master connection.
2 possible solutions: 1. State that modules should also never block the master connection. 2. Fix the replication data to be updated when the client is unblocked (in case the command blocked the client).
Comment From: oranagra
the problem is that the replication offset is linear, so in two consecutive commands that arrived, if the first one gets blocked, and the second one finished, we can't REPLCONF ACK the second without the first. i suppose we have no other resort than forbid blocking commands from the mater link.
Comment From: oranagra
ohh, scrap that, two commands arriving on the same connection can't finish out of order. so i suppose we can fix that if we have to.. should probably be part of #11012, or a separate PR right after that.
Comment From: ranshid
@MeirShpilraien one thing I do not understand is why the replication offset be updated? The commandProcessed is first verifying if the client is blocked and only then updates the repl_offset...
Comment From: MeirShpilraien
@ranshid good point, missed that, we will continue investigate and update what we found ...
Comment From: ranshid
@MeirShpilraien can we close this issue, or you did you find some bug?
Comment From: MeirShpilraien
After checking more closely I could not find any issue other then the one describe here: https://github.com/redis/redis/issues/12124 Closing this issue.