Repository navigation
Check compatibility against a real Redis, twice over - #1
Merged
Merged
Conversation
Two halves, because they catch different things. suite/fetch.sh vendors the Redis 8.10.1 release tarball's tests/ directory unmodified and suite/runtest.sh points it at a running yodb through the suite's external mode. Their tests, our server, nothing patched out. A test that fails because we have not written the command yet is still a compatibility failure, it is just one with a date on it. yocompat is the other half. It starts a real Redis and a yodb, sends both the same commands and reports every reply that is not byte for byte the same. This catches what their suite cannot, because their tests assert what their own developers thought was worth asserting and leave out everything they take for granted: that a missing key is $-1 and not _, that INCRBYFLOAT replies with a bulk string and not a double, that the first word of an error is WRONGTYPE and not ERR. Clients branch on all of it. The RESP client here is deliberately naive and has no dependencies, because a client from crates.io is written to be pleasant and turns a null bulk string and a null array into the same None. That is exactly the bug this is for. The corpus files carry no expected answers, because the expected answer is whatever Redis says. divergences.toml holds the differences we have decided to live with, each with a reason, and an entry with no reason on it does not load. suite/passing.txt is empty. The suite has not been run against yodb yet and that is the honest thing to write down until it has been.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two halves, because they catch different things.
suite/fetch.shvendors the Redis 8.10.1 release tarball'stests/directory unmodified, andsuite/runtest.shpoints it at a running yodb through the suite's own external mode. Their tests, our server, nothing patched out. A test that fails because we have not written the command yet is still a compatibility failure, it is just one with a date on it.yocompatis the other half. It starts a real Redis and a yodb, sends both of them the same commands, and reports every reply that is not byte for byte the same. This catches what their suite cannot, because their tests assert what their own developers thought was worth asserting and leave out everything they take for granted: that a missing key comes back as$-1and not_, thatINCRBYFLOATreplies with a bulk string and not a double, thatGETRANGEon a missing key is an empty bulk string and not a null, that the first word of an error isWRONGTYPEand notERR. Clients branch on all of it.The RESP client here is our own and has no dependencies. A client from crates.io is written to be pleasant, which means it normalises: a null bulk string and a null array become the same
None, a simple string and a bulk string become the sameString. Those are exactly the differences this repository exists to find, so the reader here keeps a reply as its shape and its bytes and compares it that way.The corpus files carry no expected answers, because the expected answer is whatever Redis says. Writing them down by hand would turn this into a test of our reading of the documentation. Five files so far: strings, numbers, expiry, errors and the protocol, and they are mostly edges rather than happy paths, because the happy path agrees on every server that has ever shipped.
Divergences are sorted worst first in the report. Accepting a command Redis refuses is a correctness bug that will corrupt data for a client that relied on the refusal, and refusing it with different wording is a bug too, but a smaller one.
divergences.tomlholds the differences we have decided to live with, each with a reason next to it, and an entry with no reason does not load at all.suite/passing.txtis empty. The Redis suite has not been run against yodb yet, and that is the honest thing to write down until it has been. The run comes next, on server3, against the same Redis 8.10.1 the benchmarks use.