I believe there’s a bug in the replicas in TU8: they’re not responding to REPLCONF GETACK *, which I’m using to check connectivity when I get a WAIT command.
Note that I also pass the next stage NA2 (WAIT relies on acks). But this logic is at odds with TU8 (WAIT does not rely on acks).
I do have a horrid hack to conditionally have WAIT return max connected clients when I get 0 acks… this will make me pass TU8, but I rather not do that.
Hey @HowieTKL, this is more of an edge case than an actual bug. Realistically, it’s possible that not all replicas respond within the specified timeout.
That said, I totally get why you’d rather avoid the hack.
You might want to try implementing the behavior described in the official Redis doc:
In the specific case of the implementation of WAIT , Redis remembers, for each client, the replication offset of the produced replication stream when a given write command was executed in the context of a given client. When WAIT is called Redis checks if the specified number of replicas already acknowledged this offset or a greater one.
Thanks for the info! With the current challenge, we only rely on master’s GETACK, which means if replicas never respond, the master cannot update its acks for WAIT. Problematic.
Enhancement: allow replicas to async ping acks to master. Means master does not have to rely on GETACK alone. More context to your quote above from official docs:
Since the introduction of partial resynchronization with replicas (PSYNC feature) Redis replicas asynchronously ping their master with the offset they already processed in the replication stream. This is used in multiple ways:
Detect timed out replicas.
Perform a partial resynchronization after a disconnection.
Implement WAIT.
Does seem like a nice enhancement to have. Either way, for WAIT to work optimally, replicas need to either reply to acks or async send their own acks.
