codecrafters-io / build-your-own-redis Goto Github PK

For testing the WAIT command: WAIT numreplicas timeout, when the number of numreplicas is reached, it can be returned, and any value from numreplicas to the maximum number of replicas is possible. However, the testing task requires reaching the maximum number of replicas to consider it the correct testing logic.
Specific command information can be viewed at this website address：https://redis.io/commands/wait/

This applies to all challenges - When an anti-cheat stage fails, we must say "Please contact [email protected] if you think this is an error"

remote: anti-cheat (ac1) failed.
remote: Are you sure you aren't running this against the actual Redis?

When we reuse a connection to send multiple commands, we still emit logs like this:

$ redis-cli SET a b
$ redis-cli SET b c

This can be misleading, giving the impression that these commands will be sent by different connections.

Thanks to @rsalmei for pointing this out!

rdb persistence stage 1(read config from arg) doesn't create corresponding rdb file, is it intended?
In stage 2 I implemented the server to crash when there's no rdb file but the argument is supplied.
I was figuring out why I was getting os error 2(no file) error for a while and I realized the test was failing at stage 1, not 2.

The tester is "right" here in the sense that if a file doesn't exist, the program must write it when a flush occurs.

We have two options here:

• (a) Keep existing tester behaviour, and add a comment noting this
• (b) Just create an empty .rdb file, so that users don't have to deal with this

(a) is a more "true" implementation, (b) is less confusing but still lets people deal with .rdb files and learn about them.

For instance every time I try to submit stage 3 for Redis for C++, I keep getting "undefined reference to pthread_create". I have the header files and all of the dependencies installed, so I am just confused why this keeps happening when I try to push to origin master. Is there something completely obvious I am missing?

Thanks for @SamirOsAbdalla for reporting!

Instead of just saying "Length mismatch", let's say:

Expected 28 bytes, received 24 bytes
Expected: ....
Received: ... 

We might also be able to re-use https://github.com/codecrafters-io/tester-utils/blob/master/bytes_diff_visualizer/bytes_diff_visualizer.go in some way, but probably not needed here since there's no non-ascii characters involved

I am getting following error

This happens before my redis clone is even started so I am guessing it is problem on build-your-own-redis side

Let's see if we can include the received response somewhere?

Thanks to @lipinskipawel for pointing this out!

Im having trouble with syncronization in replication command processing

I have one thread that is listening for commands (like the sets) from the master, and another that is listening for commands sent directly to my replica

Sometimes the get from the test comes before I can process the set from the master. What is the recommended approach to syncronize that?

You can see I get the first SET, then I get both GETs, and only then I get the rest of the SETs

I think we need to be either sleeping for a bit before running the GET commands, or we should retry them for a certain time period. The user's implementation seems correct from a practical perspective, it's expected that there might be a small delay between a command being propagated and it being applied on the client.

In the RDB extension, since we rely on a third-party parser, our error messages aren't very helpful.

Example:

Error while parsing RDB file : unexpected EOF

Just like we do with RESPClient, we should write our own parser that can generate friendly error messages.

Thanks to @knusth for highlighting this!

Currently we don't check the time elapsed when the WAIT command is supposed to return early.
But, as highlighted by @andy1li, this might lead to cases where user never implements WAIT properly, just sleeps for time_duration, and returns.

This can be mitigated by adding checks on elapsed_time in cases where WAIT returns early.

Thanks to @Jyuart for reporting this!

Since we're implementing INFO in the replication extension now, let's find another command that a user is unlikely to implement.

As pointed out by @LakshyaMittal3301, in the later stages, the instructions say that the response when a blocking read times out is a nil bulk string ($3\r\nnil\r\n). This is "nil" (a string), not a nil value.

The nil value representation of a bulk string is as follows $-1\r\n.

The stage instructions should be updated to reflect this.