Missing commands: DUMP/RESTORE, HSTRLEN, EVAL_RO/EVALSHA_RO, FAILOVER, MIGRATE, MODULE

[TinDang97]

Summary

Nine commands redis-server 8.6.1 answers are -ERR unknown command on Moon. Measured 2026-08-22 on moon 0.8.5+ (fd838ede), --shards 1, by SENDING each one (COMMAND INFO is not authoritative here — see #635):

DUMP <key>                    -ERR unknown command 'DUMP'
RESTORE <key> 0 <payload>     -ERR unknown command 'RESTORE'
HSTRLEN <key> <field>         -ERR unknown command 'HSTRLEN'
EVAL_RO <script> 0            -ERR unknown command 'EVAL_RO'
EVALSHA_RO <sha> 0            -ERR unknown command 'EVALSHA_RO'
FAILOVER ABORT                -ERR unknown command 'FAILOVER'
MIGRATE host port key 0 100   -ERR unknown command 'MIGRATE'
MODULE LIST                   -ERR unknown command 'MODULE'
DEBUG DIGEST                  -ERR DEBUG subcommand 'DIGEST' not supported

Suggested priority

DUMP / RESTORE first, as a pair. They are the serialisation surface: redis-cli --bigkeys-style tooling, redis-dump, key-level backup/copy scripts and every "move this key to that server" workflow use them, and neither half is useful alone. They also need an RDB-object serialiser that Moon already has most of, and a version+CRC footer clients verify.

HSTRLEN next — trivially cheap (HGET length without the transfer), and it is the one on this list a normal application (not tooling) is likely to call.

EVAL_RO / EVALSHA_RO next. Moon already routes scripts by key (#516) and already carries a ScriptAcl; the _RO forms are the same path with writes refused. They matter for read-replica routing: a client that wants to send a script to a replica has no other way to say "this script does not write". Note they are also absent from Moon's registry entirely, so COMMAND INFO EVAL_RO returns nil rather than an entry — the refuse_if_keyspace MONITOR table already has a comment anticipating them.

FAILOVER, MIGRATE, MODULE are cluster/extension surface and should follow whoever owns those areas; MODULE LIST returning *0 is worth doing on its own, since clients call it on connect to feature-detect and an error reads as a broken server.

DEBUG DIGEST is how consistency harnesses compare two datasets in one round trip; nice to have for the crash-matrix suites, not user-facing.

Also seen, deliberately excluded

Redis 8.x additions DELEX, HSETEX, MSETEX are in the same diff. They are new API surface rather than long-standing gaps and want their own decision about whether Moon tracks 8.x additions at all.

LATENCY (all subcommands), CLIENT TRACKINGINFO and FUNCTION STATS / FUNCTION DUMP are already #632.

How this surfaced

The COMMAND LIST diff in #635, taken while fixing the scripts/test-consistency.sh abort (#634).

[TinDang97]

MIGRATE — oracle capture and the design question it forces

Captured against a live redis-server 8.6.1 pair (source :6491, target :6492) on 2026-08-24, so the strings below are read, not inferred.

Wire shapes

Case	Reply
success	+OK
key absent (also: every key in KEYS absent)	+NOKEY
target unreachable / slow	-IOERR error or timeout writing to target instance
target refuses the RESTORE	-ERR Target instance replied with error: BUSYKEY Target key name already exists.
bad timeout	-ERR value is not an integer or out of range
unknown option	-ERR syntax error
KEYS with a non-empty key argument	-ERR When using MIGRATE KEYS option, the key argument must be set to the empty string

Raw bytes, so the error code is not guessed:

+OK\r\n-IOERR error or timeout writing to target instance\r\n+NOKEY\r\n

IOERR is its own error code, not an ERR subtype. NOKEY is a simple string, not an error — a client that treats a non-OK reply as failure still has to accept it.

Behaviours worth pinning

• TTL is preserved as a relative remainder (SET tk v EX 100 → target TTL = 100).
• destination-db is honoured — MIGRATE h p dk 5 1000 lands in db 5, and db 0 stays empty.
• COPY retains the source key; without it the source key is deleted.
• REPLACE turns the BUSYKEY case into +OK.
• Partial KEYS (some present, some absent) is +OK, and only the present ones move.
• timeout 0 and negative timeouts are accepted, not rejected — redis falls back to its default.
• AUTH failures are forwarded verbatim inside the Target instance replied with error: wrapper.
• On IOERR the source key survives (EXISTS → 1). That is redis's rollback rule: delete only after the target has confirmed.

The design question this raises for moon

Redis performs the whole transfer synchronously on its single thread, so no write can interleave between "serialise the key" and "delete the key". Moon cannot copy that shape for free:

• Doing blocking connect/write/read on a shard thread stalls every connection on that shard for up to timeout ms. Redis stalls too, but redis has one thread and moon's shards each serve a slice of the client population — the blast radius is different in kind.
• Doing it off the shard (connection-handler intercept, or a blocking worker with a flume oneshot reply, which is the shape that works identically under monoio and tokio) opens a window between DUMP and DEL. A write landing in that window is silently discarded by the DEL — the same data-loss class as data loss: every two-key write whose destination is not the routing key lands on the wrong shard (SMOVE, RENAME, *STORE) #592.

The safe version needs the DEL to be conditional on the entry being unchanged since the dump, and needs an answer for what to report when it has changed. That is a real decision, not an implementation detail, so I am recording it here rather than picking one silently.

Also worth noting: MIGRATE is moon's first outbound connection initiated from a client command. It needs a connect timeout, a read/write deadline, a bound on concurrent in-flight migrations, and a rollback that is proven by test rather than by reading the code — per this repo's IO rules.

The serialisation half is already done: DUMP/RESTORE landed earlier in this issue and persistence::dump_payload::{encode, decode} is exactly what MIGRATE would put on the wire.