Redis Stream discrepancies with Redis Open Source

[prabhpreet]

Hello,

I'm using Redis Streams and have noticed two discrepancies with Redis Open source (Redis version=7.2.1):

1. XREADGROUP sends nil response for blocking consumers on a group other than the consumer receiving the actual message contents.
2. XINFO CONSUMERS does not list consumers which are listening using XREADGROUP if they have not received a message yet. This is different from Redis Open Source where it shows all consumers irrespective of whether it has received a message yet.
3. I'm also curious about the strategy to balance sending messages to consumers- in the below example, the client kept delivering messages to one consumer, despite it having previous messages pending.

See below a simple test scenario with four Redis client instances- the client on the left creates a stream called ts with a group test, adds messages to the stream and lists consumers. The clients on the three columns on the right use the XREADGROUP command with consumers c1, c2, c3 to listen in a blocked fashion. Clients c1 and c3 receive nil responses when c2 recieves the actual message contents.

On multiple occasions, I have checked for registered consumers with XINFO CONSUMERS ts test which only shows c2 as a consumer since it was the only one that received the messages (no acknowledgement after). Later, a message to c1 was finally delivered (seen in screenshot here), and the other consumers received a nil response. Listing consumers with XINFO CONSUMERS after this listed c1 and c2 as consumers (not in screenshot here).

[sancar]

@prabhpreet Thanks for the report. Let me try to answer your questions 1) This seems to be a bug. You are right, the blocked consumers should continue to wait until they get actually a response. We are working on the fix.

2) Yes, this behavior is different and we are aware of it. I will open an internal ticket for this but since this is urgent we may postpone the fix.

3) The consumers are basically racing for the read. The ones available(waiting on XREADGROUP) will read first always. When there are multiple ones waiting, the implementation relies on the fairness of sync.Condition.Signal. I think we can say that it is mostly fair but not always. So first one to block on read usually gets the next items.

[prabhpreet]

Thanks, appreciate the quick response & looking forward to the fix!