Replication (#YG4) Unclear that multiple commands can be received at once

I’m stuck on Replication 13.

In level 12, I forward set request from Master to the slaves but only one request reaches slave and sometimes not even one request reaches slave. The get request afterward throw error as their is no value available because of the set request not yet processed.

Hi there!

Mind sharing logs, and some sample code? (You can use the “Publish to GitHub” button in the top-left dropdown to easily publish to github).

We do retry the GET request multiple times to account for propagation delays, and you should see this in the logs.

And just in case you haven’t already, I’d recommend turning on debug mode (instructions here). That should surface more useful logs.

I have published the code to github. Please help me here I don’t understand what is going wrong. Below are some of the logs i get

remote: [replication-13] Sent RDB file.
remote: [replication-13] master: $ redis-cli SET foo 123
remote: [replication-13] master: Sent bytes: "*3\r\n$3\r\nSET\r\n$3\r\nfoo\r\n$3\r\n123\r\n"
remote: [replication-13] master: $ redis-cli SET bar 456
remote: [replication-13] master: Sent bytes: "*3\r\n$3\r\nSET\r\n$3\r\nbar\r\n$3\r\n456\r\n"
remote: [replication-13] master: $ redis-cli SET baz 789
remote: [replication-13] master: Sent bytes: "*3\r\n$3\r\nSET\r\n$3\r\nbaz\r\n$3\r\n789\r\n"
remote: [replication-13] Getting key foo
remote: [replication-13] client: $ redis-cli GET foo
remote: [replication-13] client: Sent bytes: "*2\r\n$3\r\nGET\r\n$3\r\nfoo\r\n"
remote: [replication-13] client: Received bytes: "$-1\r\n"
remote: [replication-13] client: Received RESP value: NIL
remote: [replication-13] Retrying... (1/5 attempts)
remote: [replication-13] client: $ redis-cli GET foo
remote: [replication-13] client: Sent bytes: "*2\r\n$3\r\nGET\r\n$3\r\nfoo\r\n"
remote: [replication-13] client: Received bytes: "+123\r\n"
remote: [replication-13] client: Received RESP value: "123"
remote: [replication-13] Received "123"
remote: [replication-13] Getting key bar
remote: [replication-13] client: $ redis-cli GET bar
remote: [replication-13] client: Sent bytes: "*2\r\n$3\r\nGET\r\n$3\r\nbar\r\n"
remote: [replication-13] client: Received bytes: "$-1\r\n"
remote: [replication-13] client: Received RESP value: NIL
remote: [replication-13] Retrying... (1/5 attempts)
remote: [replication-13] client: $ redis-cli GET bar
remote: [replication-13] client: Sent bytes: "*2\r\n$3\r\nGET\r\n$3\r\nbar\r\n"
remote: [replication-13] client: Received bytes: "$-1\r\n"
remote: [replication-13] client: Received RESP value: NIL
remote: [replication-13] Retrying... (2/5 attempts)

Can you share the GitHub link too please?

Looking at the logs, it looks like your program is responding with NIL instead of the expected value (123)?

Link of the github repo

@codesbyayush the issue seems so be with how the requests propagated by the master are handled.

There are 3 separate SET commands which are propagated (i.e. all the bytes will be received at once).

In main.ts:46, the code that parses these requests assumes that there’s just one command:

  masterConn.on("data", (data) => {
    const req = data.toString().toLowerCase();
    const parsedReq = RESP2parser(req.split("\r\n"));
    ...
  };

(i.e. the first command is parsed, and the other 2 commands are ignored).

The fix here would be to change the way these messages are parsed so that your code handles multiple messages in the data string.

Hope this helps! We’ll see if we can update our instructions to make this behaviour more clear.

An update would be helpful here, I have same issue. Saw the commands and could tell it was sending multiple. But looked through instructions, including previous ones and didn’t see anything that made it clear that was possible. But it’s obvious now.

Facing a similar issue, my instance is not receiving some bytes from the server

The RDB file bytes are never received

Updated the instructions now!

1 Like

@abhiy13 this looks like a different issue, would suggest starting another topic with details so that we can take a proper look!

Note: I’ve updated the title of this post to include the stage ID (#YG4). You can learn about the stages rename here: Upcoming change: Stages overhaul