CROSSSLOT
The command will be rejected, and what to change so it is not
cart:1000 cart:1000:items cart:1000:total
Paste the keys you want to use in a single command. This says whether they all hash to one slot, and if not, what to change. A multi-key command whose keys span slots is rejected, whatever nodes those slots happen to live on.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Check. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
The command will be rejected, and what to change so it is not
cart:1000 cart:1000:items cart:1000:total
A shared tag guarantees these stay together across any resharding
{cart:1000}
{cart:1000}:items
{cart:1000}:totalThese are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
CRC16 has only 16,384 outputs, so collisions happen. The command works today and breaks the day somebody renames a key, with no warning.
Instead:If co-location is a requirement rather than luck, make it a hash tag.
It is a slot check, not a node check. Two slots on the same node today still fail, because the answer has to survive a resharding that has not happened yet.
Instead:Give the keys a shared tag, or issue one command per key.
A tag like `{batch1}` co-locates keys that only belong together briefly, and they stay clustered forever, producing a hot slot nothing can spread.
Instead:Tag the thing the keys are about: the user, the tenant, the order.
This is the distinction that makes the error confusing. Two keys can be on the same physical node today and still be rejected, because the answer has to remain correct after a resharding that Redis has not performed yet.
MGET, MSET, MSETNX, DEL with several keys, SUNIONSTORE, ZUNIONSTORE, SMOVE, RENAME, BITOP, any Lua script declaring more than one key in KEYS, and every command inside a MULTI. All of them fail with CROSSSLOT Keys in request don't hash to the same slot if the keys span more than one.
Redis could route to several nodes and merge, and deliberately does not. A multi-key operation across nodes cannot be atomic, and a Lua script cannot be, so the guarantee people rely on would silently weaken. Refusing is the honest option, and it pushes the decision back to the key design where it belongs.
Two untagged keys can collide into the same slot by coincidence, because CRC16 has only 16,384 outputs. The command works, the test passes, and then somebody renames a key and it breaks in production. If co-location is a requirement rather than a happy accident, it has to be a hash tag.
The tag should be the thing the keys are about, usually a user or tenant or order id, so that everything belonging to that entity is co-located. Tagging by operation, for example {batch1}, moves the problem: the batch is over quickly and the keys stay clustered forever, which produces hot slots that no resharding can spread out.
It cannot tell you whether the keys exist, how large they are, or whether concentrating them in one slot creates a hot spot. A tag that co-locates ten million keys makes them all one node's problem, and no error will ever mention that. It also does not apply to a standalone Redis, where every key is local and multi-key commands always work.