A RESP3 map
What a RESP2 client would have received instead: a flat array it has to pair up itself
%2\r\n$6\r\nserver\r\n$5\r\nredis\r\n$7\r\nversion\r\n$5\r\n7.2.4\r\n
Paste a reply and see which types are RESP3-only, and what a RESP2 connection would have sent in their place. This is the page for working out why a result changed shape after a client upgrade.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Compare. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
What a RESP2 client would have received instead: a flat array it has to pair up itself
%2\r\n$6\r\nserver\r\n$5\r\nredis\r\n$7\r\nversion\r\n$5\r\n7.2.4\r\n
A reply using no RESP3 types, which decodes the same whether or not the client sent HELLO 3
*2\r\n$3\r\nfoo\r\n:42\r\n
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
RESP3 is negotiated per connection with HELLO 3. The same command returns a flat array on RESP2 and a real map on RESP3, so code indexing by position breaks.
Instead:Check whether your client sends HELLO 3, and read replies by key rather than by index where the protocol allows it.
SMEMBERS on RESP2 returns an array, which implies an order that does not exist. On RESP3 it is a set and the client may hand you an unordered collection.
Instead:Sort explicitly if order matters. It never came from Redis.
The protocol version is negotiated per connection with HELLO. A client that never sends HELLO 3 gets RESP2 forever, and the same command returns a different structure on each, which is why a library upgrade can change your code's behaviour without any server change.
On RESP2, a command like CONFIG GET or XPENDING returns an array of alternating keys and values, and every client pairs them up itself. On RESP3 the same reply is a real map. Client libraries usually surface this as a dictionary rather than a list, which is the change most likely to break code that indexed the array by position.
SMEMBERS on RESP2 returns an array, which implies an order that does not exist. On RESP3 it returns a set, and a client is free to hand you an unordered collection. Code that relied on the incidental ordering of a RESP2 array will not survive that, and nothing will warn it.
On RESP2, a pub/sub message is an ordinary array, so a client has to track subscription state to know whether the thing it just read was a reply or a message. RESP3 gives push its own type, which is what makes client-side caching invalidation possible at all.
ZSCORE on RESP2 returns a bulk string the client parses; on RESP3 it is a double. A boolean is an integer 1 or 0 on RESP2 and a real boolean on RESP3. Neither loses information, but the type your code receives changes.
It cannot tell you whether your client sent HELLO 3, only what the bytes in front of it use. If a reply contains no RESP3-only types it is identical on both versions, and this page will say so rather than guess. Whether your server supports RESP3 at all depends on it being Redis 6 or newer.