When a module blocks the client using RM_BlockClient, Redis will not update the woff (Last write global replication offset) value of the current client. In case the module perform replication from a background thread, the woff value will not be updated even when the client gets unblock. This cause the wait command to be ineffective.
One possible solution is to save the replication offset in the Blocked client and check if the value was changed when the client gets unblock. The problem with this solution is that we might take write commands that was performed during the time the client was blocked but not necessarily related to the client. To solve this, we might want to consider an API, RM_BlockedClientDataChanged, that will give a hint to Redis that the blocked client changed the data and cause the replication offset to increase.
That said we might want to also consider other possibilities. Would like to get more opinion about the topic.
@yossigo @guybe7 @oranagra
Comment From: oranagra
i suggest that for now, we'll take the less optimal solution that does not involve module API changes and risk of breaking the WAIT.
i.e. either blindly update woff when unblocking, or based on some way to sense that the module replicated or modified something.
i suppose that trying to log some counter of RM_Replicate / RM_Call with ! inside the RedisModuleBlockedClient struct would be insufficient, since the module can do modifications and replicate things from other detached contexes that are not tied to that client, right?