Merge pull request #427 from codecrafters-io/TropicolX-patch-71-1

Revise "WAIT with no commands #tu8" (stage 59)

Author: TropicolX

stage_descriptions/replication-17-tu8.md

@@ -1,11 +1,25 @@
-**🚧 We're still working on instructions for this stage**. You can find notes on how the tester works below.
+In this stage, you’ll extend your `WAIT` implementation to handle the case where replicas are connected, but no commands have been sent.
 
-<!--
+### `WAIT` with connected replicas
 
-In this stage you will implement WAIT, when some replicas are connected to Master, but there have been NO commands propagated from master to replica. So offset is essentially 0. In this case, the Master can just return the count of `connected_slaves` asap.  (The replicas will finish the sync handshake with Master, so they are actually connnected.)
-(The master will return the count of `connected_slaves` no matter how many replicas we pass in the WAIT command parameter. As the offset is 0, it knows all replicas are in sync.)
+In a previous stage, we handled the case where no replicas were connected, and the master could safely return `0`.
 
--->
+Now, we’ll consider the case where some replicas are connected. Each replica will have completed the handshake and received the empty RDB file. But since no write commands have been sent yet, the replication offset is still `0`.
+
+In this situation, the master will return the number of connected replicas, since it knows they are all in sync at offset `0`:
+
+```bash
+$ redis-cli WAIT 3 500
+(integer) 7
+$ redis-cli WAIT 7 500
+(integer) 7
+$ redis-cli WAIT 9 500
+(integer) 7
+```
+
+In the example above, `7` replicas are connected. No matter how many replicas the client asks for, the master will reply with the number of connected replicas (`7`).
+
+For this stage, you can ignore both arguments (`<numreplicas> <timeout>`) and simply return the number of connected replicas.
 
 ### Tests
 
@@ -15,19 +29,19 @@ The tester will execute your program as a master like this:
 ./your_program.sh
 ```
 
-It'll then start **multiple** replicas that connect to your server. Each will complete the handshake and expect to receive an empty RDB file.
+It will then start **multiple** replicas that connect to your server. Each will complete the handshake and expect to receive an empty RDB file.
 
-It'll then connect to your master as a Redis client (not one of the replicas) and send commands like this:
+It will then connect to your master as a client and send commands like this:
 
 ```bash
 $ redis-cli WAIT 3 500 # (expecting 7 back)
 $ redis-cli WAIT 7 500 # (expecting 7 back)
 $ redis-cli WAIT 9 500 # (expecting 7 back)
 ```
 
-The response to each of these commands should be encoded as a RESP integer (i.e. `:7\r\n`).
+The response to each of these commands should be encoded as a RESP integer (i.e., `:7\r\n`).
 
 ### Notes
 
-- Even if WAIT is called with a number lesser than the number of connected replicas, the master should return the count of connected replicas.
-- The number of replicas created in this stage will be random, so you can't hardcode `7` as the response like in the example above.
+- Even if `WAIT` is called with a number less than the number of connected replicas, the master should return the count of connected replicas.
+- The number of replicas created in this stage will be random, so you can't hardcode `7` as the response, like in the example above.