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: NodeRedis#190 Signed-off-by: David Trejo <email@example.com>
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.
This will cause npm to attempt to install hiredis when installing redis, but if the hiredis installation fails, it won't cause the redis install to abort. The optionalDependencies feature was added pretty much explicitly for the redis->hiredis use case. :)
…onnect. Also fixes bug with re-selecting db when auth is required. Still needs a test for pub/sub reconnect and monitor reconnect.