RESP2 Null Array: Frame::Null always serialises as $-1, so BLPOP and friends reply the wrong type

[TinDang97]

Frame has no null-array variant, so every command whose empty answer is an array replies with the wrong RESP2 type.

Frame::Null serialises to $-1 (Null Bulk), full stop. Redis answers *-1 (Null Array) wherever the missing value is an array. A statically-typed client decodes the two differently, so this is a decode error on the client, not a cosmetic difference.

This is not a MULTI bug — it was found inside MULTI but reproduces on a plain connection:

BLPOP missing 1        # Moon: $-1     Redis: *-1

Measured inside a transaction (tests/multi_exec_queue_semantics.rs::me7):

Moon:  *1\r\n$-1\r\n
Redis: *1\r\n*-1\r\n

Why it was not fixed in #472

The fix is a Frame::NullArray variant threaded through the ~14 Frame::Null match arms in serialize.rs and resp3.rs. That touches every reply path in the server, so it needs its own contract and its own review rather than riding along inside a MULTI-semantics change. Getting it wrong flips the type of replies that are currently correct.

RESP3 is unaffected in the same way — _\r\n is the null for both shapes there — so the divergence is RESP2-only, which is also why it survived the RESP3 type-fidelity work.

Scope

• add Frame::NullArray, serialising to *-1 in RESP2 and _\r\n in RESP3
• audit every Frame::Null site and decide, per site, which null it means — the audit is the task; a blanket replace would be wrong in both directions
• blocking commands' zero-timeout path (BLPOP, BRPOP, BLMOVE, BZPOPMIN/MAX) are the known callers, but the audit governs
• un-ignore me7_blpop_in_multi_returns_null_array_not_null_bulk in tests/multi_exec_queue_semantics.rs — the assertion is already correct, only the capability is missing
• add a compat-harness entry so the oracle keeps this honest

Provenance

Unmet Must #7 of the multi-exec-queue-semantics ADD task, whose gate is recorded RISK-ACCEPTED against this issue.

[TinDang97]

Measured ground truth — Moon vs redis-server 8.6.1, RESP2

The issue says the audit is the task, so I built the table from the wire
rather than from the docs: same probe script against a live Redis and a live
Moon (--shards 1), recording the exact first bytes of each reply. Every probe
uses its own never-written key and asserts EXISTS == 0 first — v1 of the
script let one probe create nokey as a list and the rest of the table came
back WRONGTYPE.

Script: tmp/null_oracle2.py (scratch, not committed).

Divergences — 16 sites

probe	Redis	Moon
LPOP k 2 (absent)	*-1	*0
RPOP k 2 (absent)	*-1	*0
LMPOP 1 k LEFT	*-1	$-1
BLPOP k 0.05 timeout	*-1	$-1
BRPOP k 0.05 timeout	*-1	$-1
BLMOVE k d L R 0.05 timeout	*-1	$-1
BRPOPLPUSH k d 0.05 timeout	*-1	$-1
BLMPOP 0.05 1 k LEFT timeout	*-1	$-1
BZPOPMIN k 0.05 timeout	*-1	$-1
BZPOPMAX k 0.05 timeout	*-1	$-1
BZMPOP 0.05 1 k MIN timeout	*-1	$-1
ZMPOP 1 k MIN	*-1	$-1
XREAD ... STREAMS k 0-0 (absent stream)	*-1	$-1
XREAD ... STREAMS live 9999-0 (no data)	*-1	$-1
GEOPOS live-key absent-member	*1\r\n*-1\r\n	*1\r\n$-1\r\n
EXEC aborted by WATCH	*-1	$-1

Three things the table changes about the stated scope

1. Two of the sixteen are not Frame::Null at all. LPOP k <count> and
RPOP k <count> on an absent key currently return Frame::Array(vec![]) →
*0, where Redis returns *-1. A pass that only rewrites Frame::Null sites
finds neither. The *0 vs *-1 distinction is load-bearing in the other
direction too — ZPOPMIN, SPOP k <count>, SRANDMEMBER k <count>,
ZRANDMEMBER k <count>, HRANDFIELD k <count>, XRANGE, SMEMBERS,
HGETALL, SORT_RO, GEOSEARCH, LPOS ... COUNT all correctly return *0
today and must stay *0.

2. EXEC aborted by WATCH is in scope and was not listed.
src/server/conn/shared.rs:268 returns Frame::Null on a broken watch. Redis
returns *-1. This is arguably the highest-impact site in the table: every
client library decodes EXEC as an array, so the abort path — the one path
optimistic-locking code is written to handle — is the one that mis-decodes.

3. The variant must nest. GEOPOS puts the null array inside an array
(*1\r\n*-1\r\n), so Frame::NullArray has to be a normal composable variant,
not a top-level-reply special case.

Confirmed non-divergences

GET, HGET, LPOP (no count), LMOVE, LPOS, LINDEX, ZSCORE,
ZRANK (no WITHSCORE), ZRANDMEMBER/SPOP/SRANDMEMBER/HRANDFIELD
(no count), GETEX, GETDEL, SET ... GET, OBJECT ENCODING, GEODIST,
XADD NOMKSTREAM, ACL GETUSER, CLIENT GETNAME — all $-1 on both. These
are the sites a blanket replace would break, and they outnumber the sites that
need changing.

Two findings split out

The same diff surfaced two gaps that are not null-type bugs: #520
(RPOPLPUSH unimplemented) and #521 (ZRANK ... WITHSCORE unsupported — note
its absent-member reply is also *-1, so it depends on this issue's variant).