Repository navigation
RESTORE rejects valid Redis DUMP payloads: footer version gate is exact-match {0, 4, 10} #496
Description
Summary
RESTORE validates the 2-byte RDB footer version with exact matches instead of Redis's <= check, so DUMP payloads from several real Redis versions are rejected.
Details
src/redis_command.cpp:16189-16247 (RestoreCommand payload verification):
- accepts
dump_version == DumpCommand::dump_version_(= 0, EloqKV's own legacy footer,include/redis_command.h:7286), - or
dump_version == 4 || dump_version == 10(line ~16219).
Everything else hits "RESTORE payload rejected by version" (line ~16246). In particular:
| Source | DUMP footer version | Result |
|---|---|---|
| Redis 5 / 6 | 9 | rejected |
| Redis 7.0/7.2 | 11 | rejected |
| Redis 7.4+ | 12 | rejected |
| EloqKV DUMP | 10 (redis_dump_version_) |
accepted |
Redis itself accepts any version <= RDB_VERSION in verifyDumpPayload.
Impact
redis-cli --migrate-style flows and client-side DUMP/RESTORE migration from most Redis versions fail, even though the contained encodings (listpack/ziplist/intset/quicklist…) are supported by the decoder (src/redis_rdb_restore.cpp).
Suggested fix
Accept version <= 10 for the Redis-format path (the decoder's actual capability), and keep rejecting only encodings the decoder cannot parse (streams/modules), with a clear error.
Found during the module-docs review (#492); see docs/07-persistence-and-tools.md.
🤖 Found with Claude Code
Activity