Describe the bug

Command : SSUBSCRIBE

While the subscribe command allows multiple channels to be subscribed at the same time, using subscribe causes an error

Command Help shows that multiple channel inputs are possible.

To reproduce

Expected behavior

Subscribe Multiple Channels

Additional information

My Env Running With docker-compose Cluster Using blow Docker Images And Cluster Info

Using Dokcer Image : redis:7.0-rc DIGEST:sha256:bd71d9d956fd6bdab5208889bcd7a26a563e3e34c211c2d44534a2e14f304f95

127.0.0.1:6380> cluster info cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:3 cluster_size:3 cluster_current_epoch:3 cluster_my_epoch:2 cluster_stats_messages_ping_sent:5179 cluster_stats_messages_pong_sent:5349 cluster_stats_messages_meet_sent:1 cluster_stats_messages_sent:10529 cluster_stats_messages_ping_received:5349 cluster_stats_messages_pong_received:5180 cluster_stats_messages_publish_received:2 cluster_stats_messages_received:10531 total_cluster_links_buffer_limit_exceeded:0 127.0.0.1:6380> info

Server

redis_version:6.9.242 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:aa708bfe91aa2537 redis_mode:cluster os:Linux 5.10.16.3-microsoft-standard-WSL2 x86_64 arch_bits:64 multiplexing_api:epoll atomicvar_api:c11-builtin gcc_version:10.2.1 process_id:1 process_supervised:no run_id:7396d9a095b9ce5b23c9c4643a26255188ff1461 tcp_port:6380 server_time_usec:1650332952689600 uptime_in_seconds:3383 uptime_in_days:0 hz:10 configured_hz:10 lru_clock:6165784 executable:/data/redis-server config_file:/usr/local/etc/redis/redis.conf io_threads_active:0

Clients

connected_clients:3 cluster_connections:4 maxclients:10000 client_recent_max_input_buffer:20480 client_recent_max_output_buffer:0 blocked_clients:0 tracking_clients:1 clients_in_timeout_table:0

Memory

used_memory:1996328 used_memory_human:1.90M used_memory_rss:14036992 used_memory_rss_human:13.39M used_memory_peak:2071352 used_memory_peak_human:1.98M used_memory_peak_perc:96.38% used_memory_overhead:1595480 used_memory_startup:1585536 used_memory_dataset:400848 used_memory_dataset_perc:97.58% allocator_allocated:2154672 allocator_active:2584576 allocator_resident:7675904 total_system_memory:16648155136 total_system_memory_human:15.50G used_memory_lua:37888 used_memory_vm_eval:37888 used_memory_lua_human:37.00K used_memory_scripts_eval:0 number_of_cached_scripts:0 number_of_functions:0 number_of_libraries:0 used_memory_vm_functions:37888 used_memory_vm_total:75776 used_memory_vm_total_human:74.00K used_memory_functions:184 used_memory_scripts:184 used_memory_scripts_human:184B maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction allocator_frag_ratio:1.20 allocator_frag_bytes:429904 allocator_rss_ratio:2.97 allocator_rss_bytes:5091328 rss_overhead_ratio:1.83 rss_overhead_bytes:6361088 mem_fragmentation_ratio:7.09 mem_fragmentation_bytes:12057848 mem_not_counted_for_evict:8 mem_replication_backlog:0 mem_total_replication_buffers:0 mem_clients_slaves:0 mem_clients_normal:5400 mem_cluster_links:4352 mem_aof_buffer:8 mem_allocator:jemalloc-5.2.1 active_defrag_running:0 lazyfree_pending_objects:0 lazyfreed_objects:0

Persistence

loading:0 async_loading:0 current_cow_peak:0 current_cow_size:0 current_cow_size_age:0 current_fork_perc:0.00 current_save_keys_processed:0 current_save_keys_total:0 rdb_changes_since_last_save:0 rdb_bgsave_in_progress:0 rdb_last_save_time:1650329569 rdb_last_bgsave_status:ok rdb_last_bgsave_time_sec:-1 rdb_current_bgsave_time_sec:-1 rdb_saves:0 rdb_last_cow_size:0 rdb_last_load_keys_expired:0 rdb_last_load_keys_loaded:0 aof_enabled:1 aof_rewrite_in_progress:0 aof_rewrite_scheduled:0 aof_last_rewrite_time_sec:-1 aof_current_rewrite_time_sec:-1 aof_last_bgrewrite_status:ok aof_rewrites:0 aof_last_write_status:ok aof_last_cow_size:0 module_fork_in_progress:0 module_fork_last_cow_size:0 aof_current_size:0 aof_base_size:0 aof_pending_rewrite:0 aof_buffer_length:0 aof_pending_bio_fsync:0 aof_delayed_fsync:0

Stats

total_connections_received:461 total_commands_processed:935 instantaneous_ops_per_sec:0 total_net_input_bytes:97282 total_net_output_bytes:150616 instantaneous_input_kbps:0.00 instantaneous_output_kbps:0.00 rejected_connections:0 sync_full:0 sync_partial_ok:0 sync_partial_err:0 expired_keys:0 expired_stale_perc:0.00 expired_time_cap_reached_count:0 expire_cycle_cpu_milliseconds:24 evicted_keys:0 evicted_clients:0 total_eviction_exceeded_time:0 current_eviction_exceeded_time:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:0 total_forks:0 migrate_cached_sockets:0 slave_expires_tracked_keys:0 active_defrag_hits:0 active_defrag_misses:0 active_defrag_key_hits:0 active_defrag_key_misses:0 total_active_defrag_time:0 current_active_defrag_time:0 tracking_total_keys:0 tracking_total_items:0 tracking_total_prefixes:0 unexpected_error_replies:0 total_error_replies:4 dump_payload_sanitizations:0 total_reads_processed:1057 total_writes_processed:600 io_threaded_reads_processed:0 io_threaded_writes_processed:0 reply_buffer_shrinks:6 reply_buffer_expands:0

Replication

role:master connected_slaves:0 master_failover_state:no-failover master_replid:ec2f1f5972cb67c54f6b1cf8124e35e2f1900db1 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0

CPU

used_cpu_sys:1.322589 used_cpu_user:1.265571 used_cpu_sys_children:0.000000 used_cpu_user_children:0.001399 used_cpu_sys_main_thread:1.316688 used_cpu_user_main_thread:1.267466

Modules

Errorstats

errorstat_CROSSSLOT:count=1 errorstat_ERR:count=3

Cluster

cluster_enabled:1

Comment From: enjoy-binbin

see https://github.com/redis/redis/issues/8029#issuecomment-793160824 PUBSUBLOCAL is the new form of channels which is bounded to a slot (inside Redis shard). This is essential to scale the pubsub in a Redis cluster mode as the regular PUBSUB channel propagates the messages across the cluster which is not scalable. For Redis non cluster mode, the behaviour is consistent with the earlier pubsub channel. For Redis cluster mode, appropriate redirection will be provided as it will be assigned to a HASH SLOT and the data will be available only within the shard (MASTER/REPLICA) where the slot would exist.

and https://redis.io/commands/ssubscribe/ In a Redis cluster, shard channels are assigned to slots by the same algorithm used to assign keys to slots. Client(s) can subscribe to a node covering a slot (primary/replica) to receive the messages published.

Comment From: madolson

@ktj1312 You need to send two separate ssubscribe commands, like so:

SSUBCRIBE ch1
SSUBCRIBE ch2

You can still run them on the same node, they just can't be in the same command.

Comment From: ktj1312

@madolson

Now I understand the structure.

However, If multiple channels cannot be subscribed with a single command at the same time, wouldn't it be right for the document to be modified?

https://redis.io/commands/ssubscribe/

For now : Subscribes the client to the specified shard channels. Modyfied : Subscribes the client to the specified shard channel. (only one channel at one command)

This will make the command clear. Please consider that.

Comment From: madolson

You can subscribe to multiple channels, they just all have to be in the same slot. Perhaps we can make a small documentation update here. @hpatro ^ ?

Comment From: enjoy-binbin

https://github.com/redis/redis-doc/pull/1883 the doc has been updated, closing