[mcatanzariti]

Problem

A single SSUBSCRIBE must name one slot, but a PubSubStream may add shard channels of other slots afterwards through PubSubStream::ssubscribe. close and Drop then released them all in one SUNSUBSCRIBE, which the cluster connection routed as a single-slot command and refused at feed time with MismatchedKeySlots:

• close returned the error;
• Drop swallowed it (fire-and-forget);
• every subscription stayed on its master and in the client's registry;
• the next ssubscribe on the same Client stalled (observed: the new test hangs on main).

Note: the reported reproduction (client.ssubscribe(["doc:{a}", "doc:{b}"])) actually fails earlier, at the subscription itself, with MismatchedKeySlots. The leak happens when a stream accumulates slots one ssubscribe at a time.

Fix

A SUNSUBSCRIBE naming several slots is routed through the multi-shard policy, one slice per slot (not per node: Redis refuses a cross-slot SUNSUBSCRIBE even when both slots live on the same node). The router matches acknowledgements per channel, so the caller is answered once every master has confirmed. A single-slot SUNSUBSCRIBE keeps the cheaper single-shard path.

Tests

• dropping_a_shard_stream_spanning_slots_releases_every_slot_in_cluster: drop, re-subscribe, and check messages arrive from both masters. Hangs on main, passes here.
• closing_a_shard_stream_spanning_slots_succeeds_in_cluster: close and an explicit cross-slot sunsubscribe. Fails on main, passes here.
• ./run_tests.sh --hermetic and clippy clean. Pub/sub and cluster suites run against a local 3-master cluster: no new failure (the remaining ones need replicas / spare nodes / Redis 8 and fail identically on main).

---

Generated by Claude Code