I was attempting to design a system for solving these challenges around the official Redis documentation and ran into an interesting problem that I wanted to clarify.
In this stage, we’re using internals (replconf) to essentially send a health check to each of the connected replicas as well as confirm the offset they’re tracking is up to date.
My original understanding was that this offset strictly tracks the replication stream, which by definition only includes commands which would change the state of the dataset. My confusion is that the instructions for stage 15 seem to imply that the offset is tracking every single byte (including internal protocol like the “GETACK” command).
Link to offical docs:
I think that this may be incorrect and wanted to clarify this. Passing the stage is totally possible without nitpicking, but I wanted to maybe add logic down the line to recover from network issues if the offsets don’t match, and I think tracking the internal commands along with the replication stream offset complicates that a lot.
Hey @jdpolicano - good question! When @ryan-gang and I were working on building this extension, we actually had to check thrice to make sure this is the case The offset DOES include GETACKs, and this also means that the GETACK is actually sent to the replication stream (i.e. when sent it is sent to all replicas)
The offset DOES include GETACKs, and this also means that the GETACK is actually sent to the replication stream (i.e. when sent it is sent to all replicas)