Before the new PUB/SUB extension was introduced to the Redis challenge, I had already completed the entire List extension, including EC3 and XJ7.
However, when I started the new PUB/SUB extension, I was forced to make some slight changes to my implementation of the BLPOP command and to any related commands that were affected before the List extension test was able to pass despite MX3’s main test passing (test that the subscribe command works).
Additionally, I naturally implemented ZC8 multi-client support while creating the subscribe command and was expecting it to pass right away. However, despite its main test passing now, I have been fighting good few hours because either EC3 or XJ7 tests fail during ZC8 test execution, depending on what I try to do to fix the problems.
By now, it seems as if those tests are completely inconsistent with each other and with test sets from other stages, considering how my solution has been able to pass all previous stages. Is there a way to prevent this with some weird code fix or not?
Hey @Jhoneagle, failing previous stages does not necessarily means the tests are inconsistent.
Just for context, all test cases (including EC3, MX3, and ZC8) have been validated against the official Redis, so we’re fairly confident in their accuracy.
That said, we’re happy to dig in further if anything still seems off!
Looking at the screenshot for #EC3, the server should return [“pineapple”, “mango”] to client-2, since “mango” was just pushed by redis-cli:
