Redis redis-cli should understand push messages in RESP3

At least Pub/Sub and client tracking should be usable. That's just a matter of implementing it in hiredis, not too complex, but hiredis code tends to be a bit hard to manage so there is to check how to really implement it without big issues. I could have something already in place from the POV of refactoring in antirez/hiredis.

Comment From: antirez

Rescheduled for 6.0.1.

Comment From: michael-grunder

I just happened to stumble across this issue.

We added support for push messages in redis/hiredis#819.

Using hiredis master and making the following change to redis-cli.c gets RESP3 subscribe/psubscribe working for me:

I'll take a look at what would be required to properly handle client tracking.

diff --git src/redis-cli.c src/redis-cli.c
index 75845f346..63d317b2b 100644
--- src/redis-cli.c
+++ src/redis-cli.c
@@ -954,6 +954,7 @@ static sds cliFormatReplyTTY(redisReply *r, char *prefix) {
     case REDIS_REPLY_ARRAY:
     case REDIS_REPLY_MAP:
     case REDIS_REPLY_SET:
+    case REDIS_REPLY_PUSH:
         if (r->elements == 0) {
             if (r->type == REDIS_REPLY_ARRAY)
                 out = sdscat(out,"(empty array)\n");
@@ -961,6 +962,8 @@ static sds cliFormatReplyTTY(redisReply *r, char *prefix) {
                 out = sdscat(out,"(empty hash)\n");
             else if (r->type == REDIS_REPLY_SET)
                 out = sdscat(out,"(empty set)\n");
+            else if (r->type == REDIS_REPLY_PUSH)
+                out = sdscat(out,"(empty push)\n");
             else
                 out = sdscat(out,"(empty aggregate type)\n");
         } else {

$ src/redis-cli -3 subscribe foo bar
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "foo"
3) (integer) 1
1) "subscribe"
2) "bar"
3) (integer) 2

Comment From: michael-grunder

I implemented support for RESP3 push messages in redis-cli in a branch on my fork. I'll hold off opening a PR until hiredis v1.0.0 GA is released.

The change fixes redis-cli so that RESP3 PUSH messages are handled correctly (either in pubsub mode, or if the user enables client tracking). I wasn't really sure how we'd want to handle displaying the messages so I added an option --print-push-msgs users can enable if they want to see invalidation replies.

Comment From: michael-grunder

I've opened #7609 with a decent starting point for this functionality.

I'm happy to rework the logic if you'd like to see push messages displayed differently or think there are saner defaults.

Also no pressure, I know you are all swamped. :smile:

Comment From: michael-grunder

Now that #7609 has been merged, I think we can close the issue.

Also, I'm happy to assist if we encounter bugs/oversights with the PR.

Comment From: oranagra

@michael-grunder thanks a lot!