Originally reference from redis/redis#12311.

Nit Title: Extended Client Introspection functionality

The default behavior for CLIENT LIST API is all filters, and with that the response payload can be pretty huge. I think valkey-cli kind of gets stuck. With CLIENT DESCRIBE we can look to move away from the text format and have RESP format and get paginated response or adding a default COUNT value to restrict the payload size. I had tried that here redis/redis#11907.

The downside of introducing the new API is maintaining two set of API(s) and no guarantee of administrator(s) of moving to this.

Nit Title: Extended Client Introspection functionality

Old habits die hard.

The default behavior for CLIENT LIST API is all filters, and with that the response payload can be pretty huge. I think valkey-cli kind of gets stuck. With CLIENT DESCRIBE we can look to move away from the text format and have RESP format and get paginated response or adding a default COUNT value to restrict the payload size. I had tried that here redis/redis#11907.

I think you raise a really good point. We could add a pagination functionality by doing client-list based off of ID, and add that to client list. I think we have seen that people generally don't migrate to new commands, so it probably makes more sense to enhanced the ones we have.

@valkey-io/core-team I'm happy to take this issue up if this is an approved change. Please let me know if I can proceed.
We would be introducing some new filters to existing COUNT, KILL and LIST sub commands.
Also, would like to know if we would want to paginate the results in the current list command?

We can abstract the current filtering logic out (and add new filters) and then use it in different commands as required. In my opinion, CLIENT DESCRIBE (if approved) should be taken in a separate PR.

I feel CLIENT LIST API would have the maximum benefit out of this filters extension as the response payload can be limited through it. @valkey-io/core-team Please add your thoughts on this. @sarthakaggarwal97 is trying to come up with a solution.

CLIENT KILL has more filters than any other. Let's first add the missing ones of those to CLIENT LIST, to unify them. We can de-duplicate the parsing code too. That's a good PR to start with IMHO.

Sorry, is there the command CLIENT COUNT? new command?

I like this idea. In #1398 , I hope we have a CLIENT KILL FLAGS command.

I would like to summarize the issues that we are going to solve under #668. Please feel free to add any that I have missed.

1. Implement KILL subcommand filters to LIST, and dedup parsing and filtering. (PR Adding Missing filters to CLIENT LIST and Dedup Parsing #1401 in progress)
2. Extend the current filters to the list mentioned in the issue description.
3. Introduce a new CLIENT COUNT command to return the count of clients based on the filters.
4. Introduce a new CLIENT DESCRIBE command to scope down the fields from client info as requested by user.

@valkey-io/core-team are we good to proceed with all the above mentioned issues?

I can come with the separate issues for each, so this can be picked up by multiple people. We can even discuss in detail about each of these in their respective issues.

To me, it seems safe to proceed with 1-3.

For 4, I think we should discuss it a bit more first. I don't want to add a new command that almost nobody will use (like CLUSTER SHARDS) so I want to have a good motivation about uses cases and the features (more fields? pagination?), the syntax, etc.