Describe the bug A short description of the bug. Redis 6.2.6 In Redis Pub/Sub, the client subscribes with [SUBSCRIBE ch-food ch-sports] command, If it publish the PUBLISH ch-food "chicken" message, subscribers correctly receive the "chicken" message. So, if UNSUBSCRIBE ch-food command is used to cancel the ch-food subscription, the output is as follows. 3) (integer) 0 <-- The returned value should be 1 instead of 0, which is considered a bug or error. UNSUBSCRIBE ch-food output: 1) "unsubscribe" 2) "ch-food" 3) (integer) 0
You can see that the [ 3) (integer) 0 ] line cannot unsubscribe. Still, publish ch-food "chicken", subscribers receive it.
To reproduce Steps to reproduce the behavior and/or a minimal code sample.
[client-1] 127.0.0.1:9379> PUBLISH ch-food "chicken" (integer) 3 127.0.0.1:9379> UNSUBSCRIBE ch-food 1) "unsubscribe" 2) "ch-food" 3) (integer) 0 127.0.0.1:9379> PUNSUBSCRIBE ch-fo 1) "punsubscribe" 2) "ch-fo" 3) (integer) 0 127.0.0.1:9379> PUBLISH ch-food "chicken" (integer) 3
[client-2] 127.0.0.1:9379> SUBSCRIBE ch-food ch-sports Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "ch-food" 3) (integer) 1 1) "subscribe" 2) "ch-sports" 3) (integer) 2 1) "message" 2) "ch-food" 3) "chicken" 1) "message" 2) "ch-food" 3) "chicken"
[client-3] 127.0.0.1:9379> PSUBSCRIBE ch-fo Reading messages... (press Ctrl-C to quit) 1) "psubscribe" 2) "ch-fo" 3) (integer) 1 1) "pmessage" 2) "ch-fo" 3) "ch-food" 4) "chicken" 1) "pmessage" 2) "ch-fo" 3) "ch-food" 4) "chicken"
Expected behavior A description of what you expected to happen. After the UNSUBSCRIBE ch-food and PUNSUBSCRIBE ch-fo* commands, client are still received and listening on that channel.
Additional information Any additional information that is relevant to the problem. Included in the above mentioned.
Comment From: ranshid
@Virusuki I would like to help, but I am not sure I understand the problem. in the example you provided: client 1: is not registered to any channel or pattern so the return value (integer) is 0 client 2+3: I did not see where/if they unsubscribed from any channel, so they will keep on getting publish massages.
what am I missing?
Comment From: ranshid
Oh - just noticed to the publish response (3) can you provide a client list output of this scenario that we can make sure no other client is registered ?
Comment From: Virusuki
As you can see in the picture, 127.0.0.1:9379> unsubscribe ch 127.0.0.1:9379> punsubscribe ch
to the next step, If client send the message 127.0.0.1:9379> PUBLISH ch-food "apple", Messages are being received from SUBSCRIBE ch-food ch-sports and PSUBSCRIBE ch-fo* on the client.
I think it's normal if the subscriber doesn't receive the message, is it a pubsub bug? Or am I using it wrong?...
And, in the output below, if the unsubscribe and punsubscribe ch* commands were normally executed, shouldn't it be [3) (integer) 1]?
127.0.0.1:9379> unsubscribe ch 1) "unsubscribe" 2) "ch" 3) (integer) 0 127.0.0.1:9379> punsubscribe ch 1) "punsubscribe" 2) "ch" 3) (integer) 0
Finally, I used UNSUBSCRIBE & punsubscribe ch* commands. Why does PUBSUB numsub and PUBSUB numpat output 1? I think my expectation is 0, should I judge it as an error?
Comment From: ranshid
@Virusuki So: client 6: is not subscribed to any channel or pattern and publishing msgs client 5: is subscribed on 2 channels (ch_food and ch_sports) - so it will receive any msg published on channel ch_food or ch_sports client 4: is subscribed on a pattern ch_fo* so it will receive all msgs published on channel ch_food (in your case) So I do not see any bug here
the unsubscribe/punsubscribe return the number of channels/pattern THIS client is currently registered on, and since it is not registered on any channel/pattern you get 0. The PUBSUB command provides introspection about the current global state of the channels and pattern and not the state in the context of the current client like stated here
Returns the number of subscribers (exclusive of clients subscribed to patterns) for the specified channels.
So again I do not see any bug in your case.
Comment From: Virusuki
Thank @ranshid for your feedback. :) How do I do client 5 and client 4 to do unsubscribe and punsubscrib? You can no longer type CLI command at Terminal 5 of the Client. (state press Ctrl-C to quit) The same is true for client 4. (state press Ctrl-C to quit)
Comment From: ranshid
Well it is possible to run some subset of command while in subscription mode. specifically when using resp2 you can run a limited set of commands like stated here:
A client subscribed to one or more channels should not issue commands, although it can subscribe and unsubscribe to and from other channels. The replies to subscription and unsubscribing operations are sent in the form of messages, so that the client can just read a coherent stream of messages where the first element indicates the type of message. The commands that are allowed in the context of a subscribed client are SUBSCRIBE, SSUBSCRIBE, SUNSUBSCRIBE, PSUBSCRIBE, UNSUBSCRIBE, PUNSUBSCRIBE, PING, RESET, and QUIT.
please also note that redis-cli has some limited support as also stated in the documentation:
Please note that redis-cli will not accept any commands once in subscribed mode and can only quit the mode with Ctrl-C.
but you can use telnet to test it
Comment From: Virusuki
Okay, thnks you.! Should I understand that UNSUBSCRIBE & PUNSUBSCRIBE cannot be tested and verified in redis-cli mode?
Comment From: ranshid
right
Comment From: ranshid
But you can inject ctrl-C in order to unsubscribe the client from the channels