Skip to content

Make sure the new output of COMMAND doesn't break old redis-cli #10028

@oranagra

Description

@oranagra

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?

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions