Pub sub mode fix#190
Merged
Merged
Conversation
The test demonstrates failure for the following scenario. A single-subscription client calls unsubscribe immediately followed by a subscribe. It will fail when it tries to receive the next pmessage/message because the client will be in false pub_sub_mode. Here is why it is false: First, the 2nd subscribe sets pub_sub_mode to true during send_command. Next, the unsubscribe's return_reply sets pub_sub_mode to false. The 2nd subscribe's return_reply does not re-set pub_sub_mode back to true. So the result is a client with false pub_sub_mode that fails upon receipt of the next message or pmessage.
Contributor
|
Thank you brian! |
Contributor
|
Thanks for the fix, @bnoguchi. |
DTrejo
pushed a commit
that referenced
this pull request
Apr 30, 2012
Tests for a bug where the client unsubscribes and then subscribes to a single channel. If the subscription is sent before the response to the unsubscribe is received, then the client would leave pubsub mode when it received the unsubscribe response and then fail to enter when the subsequent subscription is processed. This is another test for #190: #190 Signed-off-by: David Trejo <david.daniel.trejo@gmail.com>
Closed
supercoder1213
added a commit
to supercoder1213/redis
that referenced
this pull request
Feb 1, 2023
Tests for a bug where the client unsubscribes and then subscribes to a single channel. If the subscription is sent before the response to the unsubscribe is received, then the client would leave pubsub mode when it received the unsubscribe response and then fail to enter when the subsequent subscription is processed. This is another test for #190: redis/node-redis#190 Signed-off-by: David Trejo <david.daniel.trejo@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Failure will occur in the following scenario:
A single-subscription client (i.e., a client that called subscribe just once before) calls unsubscribe immediately followed by a subscribe (the 2nd call to subscribe). It will fail when it tries to receive the next pmessage/message because the client will be in false pub_sub_mode.
Here is why it will have false pub_sub_mode:
First, the 2nd subscribe sets pub_sub_mode to true during send_command. Next, the unsubscribe's return_reply sets pub_sub_mode to false. The 2nd subscribe's return_reply does not re-set pub_sub_mode back to true. So the result is a client with false pub_sub_mode that fails upon receipt of the next message or pmessage.
This pull request adds both a test to demonstrate the failing scenario and a fix for it that sets pub_sub_mode to true upon receipt of a subscribe reply.