I’ve tried various approaches, both using asynchronous tasks and thread pools, but in some tests (especially the most recent one involving replicas), the replica doesn’t respond within the time set by the client, despite sending commands for all the requests. Could this be due to running remotely, where connection delays or distance affect the timing? The code looks correct to me, but it fails to execute each task promptly and send the response on time, like in the example below.
the problem is with the errors in which it tells me that the time has expired, although it should have been able to execute all the tasks.
Stage #NA2 AND STAGE #TU8. this is link to my source code : GitHub - Simioniuc-Ionut/Redis-project-python. and this is some photos with tests :
i cant put photos. i will put on github on folder “Test_images” with names :4.14.1.wait_for_multiple_commands_multiple_replica(1 to 6)
Sorry for the delayed response. After correcting a small typo, I could run your code, and it passed all the tests.
Yes, I could see some timeouts in your images, and they were expected. For context, our tester would randomly choose not to ACKnowledge certain requests, in order to test whether your implementation is correct.
In the following example, replicas 2 and 3 didn’t respond, and your code correctly labelled them as 0:
Does this answer your question? @Simioniuc-Ionut
So, is the code correct? I think there could be a problem with the previous stage because the test expects to receive acknowledgments (ACK) from all replicas, but none manage to respond within the time set by the client. You could check the exact tests from the previous stage. As a potential solution (although I don’t think it’s 100% correct), I treated this scenario by counting all replicas sent, whereas in the real stage, you can see that my code couldn’t count them.
@Simioniuc-Ionut Yep, your code behaves correctly for the last stage, according to our tests.
For the previous stage #tu8, I agree that counting all replicas sent doesn’t sound like it’s general enough. And the if statement looks like overfitting our tests:
A more general approach would count the number of replicas whose offsets match the master’s offset at the time of receiving the WAIT command.
Your workaround worked because #tu8 involves no set commands, so all replicas are up to date by default.
The official Redis doc explains the behavior of the WAIT command:
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. WhenWAITis called Redis checks if the specified number of replicas already acknowledged this offset or a greater one.
It works. Thank you <3. But I have another question. How could I run my own tests locally to create different scenarios or to make an application review where I connect more clients and demonstrate how my application works and how well it is made? Because I always run the same tests remotely.
În vin., 27 sept. 2024 la 20:15, andy1li via CodeCrafters <notifications@codecrafters.discoursemail.com> a scris:
@Simioniuc-Ionut You can refer to our tester as a blueprint for creating different scenarios locally. Feel free to use it as inspiration to meet your customized needs.
This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.