Redis ConsistentScatter psubscribe breaks any subsequent commands

[corymurphy]

Describe the bug

If you run the psubscribe command, then run any other command, the proxy seems to be stuck and no subsequent commands work. Every subsequent command returns the following...

ERR only (P)SUBSCRIBE / (P)UNSUBSCRIBE / PING / QUIT allowed in this context

To Reproduce

Steps to reproduce the behavior:

1. Start shotover
2. Run redis-cli -u redis://localhost:6379/0 psubscribe sidekiq:config
3. Open a new terminal
4. Run redis-cli -u redis://localhost:6379/0 info (or any command)

Configuration

Topology

---
sources:
  redis_prod:
    Redis:
      listen_addr: 0.0.0.0:6379
chain_config:
  redis_chain:
    - ConsistentScatter:
        write_consistency: 2
        read_consistency: 2
        route_map:
          one:
            - DebugPrinter
            - RedisTimestampTagger
            - RedisSinkSingle:
                remote_address: aws-elasticache-instance-1
          two:
            - DebugPrinter
            - RedisTimestampTagger
            - QueryTypeFilter:
                filter: Read
            - QueryTypeFilter:
                filter: PubSubMessage
            - RedisSinkSingle:
                remote_address: aws-elasticache-instance-2
source_to_chain_mapping:
  redis_prod: redis_chain

Please include any configuration for setting up services such as docker-compose that the topology.yaml depends on.

Expected behaviour

I would expect the redis psubscribe command to have the same behavior as connecting directly to the redis instance. I should be able to run other commands after subscribing.

Please include any configuration for setting up services such as docker-compose that the topology.yaml depends on.
ame way it behaves when I directly connect to a redis instance.

Systems and Version:

• ubuntu 20.04
• 0.1.1 (i've also tested this on the head of the main branch)
• Version of 3rd party software e.g. Cassandra, Redis
  • redis-cli 5.0.14
  • redis server in aws elasticache 5.0.3

Additional context

n/a

[aembke]

Just a heads up to the shotover maintainers on this one. I had a similar issue with fred.

PSUBSCRIBE and friends (any of the pubsub commands) are unique relative to the other redis commands. Normally with redis you send out one frame (usually an array of bulk/blob strings) and get back one frame (always an array of arbitrary frame types).

However, the pubsub commands actually return multiple top level arrays of responses. The number of top level array response frames is always equal to the number of patterns or keys provided in the request portion of the command. Practically speaking this means you need to call the redis protocol parser multiple times to parse the full response or your codec will incorrectly associate response frames with requests going forward.

In fred I do this by setting some state on the codec to track the number of expected response frames, and I buffer those in memory until all expected frames are received. Depending on your use case you may want to collapse those into one array of responses, or maybe not in this case if you're just proxying the responses to another connection.

This may not be related to the actual issue, but PSUBSCRIBE and friends can be tricky to handle in any app that parses redis frames directly.

[rukai]

RedisSinkSingle, the transform mentioned in this issue supports pubsub as of #645

RedisSinkCluster still does not support it, but that is tracked in #1612

Also, the ConsistentScatter transform was recently removed for reasons listed in the PR.