[mcatanzariti]

Problem

The server requires one slot per SSUBSCRIBE, and the client refused a cross-slot one with MismatchedKeySlots. So client.ssubscribe(["doc:{a}", "doc:{b}"]), the exact reproduction of the original report, failed outright, while the matching SUNSUBSCRIBE has been split per slot since #132.

Change

A shard subscription is per channel, so nothing is atomic about subscribing to several at once. A SSUBSCRIBE naming several slots is now routed like a cross-slot SUNSUBSCRIBE: one slice per slot, each to the master owning it (through the route classifier from #133, so check_routable accepts it too). The router matches confirmations by name, so the caller is answered once every master has confirmed.

The documentation of PubSubCommands::ssubscribe described SUBSCRIBE and linked to it; it now describes shard channels and the per-slot split.

Listed under Changed in the changelog: it is a visible behaviour change (an error became a success), not a fix.

Trade-off

As with a plain SUBSCRIBE, which is already split per node, a hard failure on one slice (not a redirection, which the multi-shard path replays) can leave the other slices subscribed while the caller gets an error. Refusing cross-slot subscriptions outright avoided that, at the cost of the API the report expected.

Tests

• a_cross_slot_ssubscribe_is_split_per_slot_in_cluster: the report's reproduction run to the end. It subscribes to two slots on two masters, receives from both, drops, waits until no master holds the channels, and repeats. Fails on main with MismatchedKeySlots, passes here.
• It replaces a_refused_cross_slot_ssubscribe_leaves_the_client_usable from fix(cluster): refuse an unroutable command before recording anything #133, whose premise (a refused SSUBSCRIBE) no longer exists. The routing-refusal path is still covered by a_pipeline_with_a_cross_slot_command_runs_nothing.
• Clippy -D warnings, ./run_tests.sh --hermetic, and the cross-slot and pub/sub tests on a local 3-master cluster pass.

---

Generated by Claude Code