Once subscribed (RESP2), a client may only issue SUBSCRIBE/UNSUBSCRIBE/PSUBSCRIBE/PUNSUBSCRIBE/SSUBSCRIBE/PING/RESET/QUIT until it unsubscribes - other commands error.
Pattern subscriptions: `PSUBSCRIBE news.*` matches wildcard channels; `SSUBSCRIBE` for sharded pub/sub (used across cluster shards).
Unsubscribe: `UNSUBSCRIBE mychannel` (or no arg to leave all).
In RESP3 the client can issue ANY command while subscribed (after HELLO 3).
Python redis-py: `r.pubsub(); sub.subscribe('ch'); for m in sub.listen(): ...`; publisher `r.publish('ch','msg')`.
Pub/sub messages are fire-and-forget - messages published when no subscriber is connected are dropped (unlike a queue).
Known gotchas
Pub/sub has NO message persistence - if a subscriber disconnects or isn't subscribed yet, messages are lost; use lists (RPUSH+BLPOP) or streams for durable queues.
PUBLISH returns the count of connected subscribers; 0 means nobody got it.
In a non-sharded setup pub/sub does not scale across multiple Redis Cluster nodes unless you use sharded pub/sub (SSUBSCRIBE) - a cross-node PUBLISH may not reach subscribers on another node.
A subscribed RESP2 connection is single-purpose - you typically need a dedicated connection/thread for the subscriber so it can keep listening.
Give your agent this knowledge — and 17,500+ more routes
One MCP install gives any agent live access to the full route map across 6,000+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?