I think we can also submit a PR to hiredis repo if this is accepted

@michael-grunder please take a look.
@huangzhw can you please edit the top comment to show an example of redis-cli's wrong output?
do you think it's a good idea to add a redis-cli test for it (tests/integration/redis-cli.tcl)

I'm not sure whether we should add it. In fact this is hiredis codes.

Hi @oranagra and @huangzhw,

This behavior was fixed for hiredis in these commits, although not specifically for handling in redis-cli. The changes to hiredis made the assumption that we could get a PUSH reply at any time (as long as they were not embedded in other replies).

The hiredis changes also appear to correct the redis-cli issue:

❯ src/redis-cli -3
127.0.0.1:6379> client tracking on
OK
127.0.0.1:6379> get hello
"1"
127.0.0.1:6379> set hello world
-> invalidate: 'hello'
OK
127.0.0.1:6379> get hello
"world"
127.0.0.1:6379>

If it's preferable to use this logic in hiredis instead that's OK with me too. I can go through it in detail to make sure we don't change any API behavior.

Is there a hiredis release we should upgrade to, or a planned one? I rather not cherry pick commits or make local changes.

The newest version of hiredis v1.0.2 simply has the CVE overflow fix, but I think there have been enough new features to warrant a hiredis release, which I'm happy to put together.

That said, it's probably worth letting that live in the wild for a while before integrating it back into Redis proper.

Redis 7.0 RC1 is planned for the end of the year, let's aim there for a new hiredis too?

Sure, that works for me.

created #9706, closing this one.