If you execute a lua script, you are able to execute commands that cross slots, example:
127.0.0.1:6379> eval "redis.call('get', 'foo'); redis.call('get', 'bar');" 0
(nil)
The comparable multi-exec command is blocked:
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> get foo
QUEUED
127.0.0.1:6379(TX)> get bar
QUEUED
127.0.0.1:6379(TX)> exec
(error) CROSSSLOT Keys in request don't hash to the same slot
I couldn't find any explicit examples one way or another if this was intentional behavior, but it seems inconsistent to allow atomic updates across slots. EDIT: I know this is an anti-pattern of not pre-declaring keys, but still feels like a problem.
I think the simplest solution is just to assign a "slot" to a script execution and throw an error on cross slow boundaries, but we need consensus if we are okay with this being a breaking change.
Comment From: madolson
Add a config to allow functions/script to opt-out. If an eval doesn't define a script, then it will be opted out. I'm going to propose allow_non_local_keys or non_cross_slot_keys.
Comment From: oranagra
IIRC we said it'll be a shebang flag for EVAL, and a Function flag for Functions.
so for EVAL scripts with no shebang, they'll have the permissive backwards compatible default.
but for Functions and Eval scripts that did declare a shebang, the default will be restrictive.
we could add both allow_non_local_keys and allow_cross_slot_keys (each of them is a slightly different violation).
Comment From: enjoy-binbin
i suppose it was fixed in #10615, closing
Comment From: madolson
Yeah, this wasn't a complete fix, but I guess we won't actively do more than this.