Looks like old versions o hiredis don't support so many nested multi-bulk levels.

oran@Oran-laptop:~/work/redis$ redis-cli 
127.0.0.1:6379> ping
Error: No support for nested multi bulk replies with depth > 7

alternatives: 1. remove the command arguments metadata from COMMAND, and add a new sub-command (COMMAND ARGS) that returns only the arguments. (redis-cli will try to call both) 2. remove the arguments metadata from COMMAND and add another sub-command (COMMAND DETAILS) that returns everything (redis-cli will try the new one, and fall back to the old one). 3. similar to 2, but completely deprecated plain COMMAND (no arguments), and remove all the new metadata from it (it'll have the same response as it did in 6.2), putting all the new metadata only in the new COMMAND DETAILS (all clients will have to start calling the new sub-command and fallback to the old) 4. add a new COMMAND DETAILS sub-command which will include all the metadata fields that are just relevant for documentation, and remove these from the normal COMMAND command. most clients will just need to issue COMMAND. and redis-cli will need to issue both.

So if we go with 4 it'll look like this: * COMMAND * all the old fields for backwards compatibility * key-specs * hints * sub-commands * COMMAND DETAILS * summary * since * group * complexity * doc_flags * deprecated_since * replaced_by * history * arguments * returns (not yet implemented)

if we do that, maybe the additional fields in COMMAND can be put in the original array rather than add a map?

Comment From: zuiderkwast

I prefer 2 or 3.

The name COMMAND CMDS is a bit doubled though if CMDS is short for commands. How about COMMAND DETAILS?

Comment From: kukey

I prefer 2, and i think COMMAND DETAILS is more better.

Comment From: oranagra

Updated the top comment with the better name.

@redis/core-team please suggest / comment.

Comment From: oranagra

after a discussion with @yossigo i've added option 4, which we both support.

Comment From: zuiderkwast

No. 4 looks good. Doesn't it contain the command name, or is that simply a key in a map? Like this:

{
    "get": {
        "summary": "...",
        "since": "1.0",
        ...
    },
    ...
}

Comment From: oranagra

in COMMAND it's the first entry in the nested array. in COMMAND DETAILS it would probably be the key in the map. but anyway, that list wasn't meant as an explicit design, but rather just to show that what's needed by client applications / client libraries and proxies will be put in COMMAND. and what's needed for documentation and introspection purposes will be put in the new sub-command.

Comment From: soloestoy

vote for COMMAND DETAILS

Comment From: oranagra

discussed this in a core-team meeting, decided to proceed with plan 4. extract all the doc related fields to COMMAND DETAILS. the plain old COMMAND will contains all the historical fields, as well as: * key-specs * client hints * sub-commands (each with it's own nested meta data)

these will be put as elements in the response array (not a map)