Ran Shidlansik

> @ranshid the other PR was merged, please merge unstable into this one, p.s. discussed it and conceptually approved it in a core-team meeting. @oranagra @guybe7 I have committed the...

> @ranshid not sure if it was already discussed, but do we plan to let modules enjoy the new logic? i.e. instead of a module having to provide a `reply_callback`,...

> @ranshid what's the status here? i'm afraid that it'll go stale and be hard to pick back up. @oranagra I do not think there is a new status to...

@oranagra I merged unstable and checked that local tests are passing. Can we progress with this PR or do you identify something still missing?

@oranagra took your small fixes (aside from one comment I did not understand) as well as place some more points to the top comment. From my pov this is ready...

@oranagra - please note the last commit to handle the race condition in `Blocking XREADGROUP for stream key that has clients blocked on list`

>What about clusters with small amount of keys, lets say 200 heavy keys distributed to different slots, would i need to run 16384 scans to get all the keys in...

@CharlesChen888 thank you very much for this very important proposal! some point I would like to share: > The main problem is that while using XREAD or XREADGROUP to remotely...

> How important is it to support RESP2 clients actually? Let's consider requiring RESP3 for this? I think that most clients are still defaulting to resp2 and resp3 is not...

> A problem with new SUBSCRIBE variants is that clients need to adapt to be aware of this. The [S|P]SUBSCRIBE commands troublesome because they don't have any in-band reply (in...