Open chapost1 opened 3 months ago
Seems like this bug is already fixed in v5
That's my version of not-so-elegant fix:
// @ts-expect-error (break type of eval() command)
client.eval = async (script: string, options: {keys: string[], arguments: string[]}) => {
return await client.sendCommand(
// @ts-expect-error (expected type is RedisCommandArgument)
options.keys[0], // firstKey
false, // isReadonly
['EVAL', script, `${options.keys.length}`, ...options.keys, ...options.arguments]
)
}
It works in my case, and at least without forks
Description
EVAL && EVALSHA commands infers wrong node by key hash slot on cluster mode.
Usage in abstract:
As of my understanding each command uses the
FIRST_KEY_INDEX
function that's defined in it's module and then based on that the node is inferred based on the hash slot of first key.On file:
There is generic function that is used to extract firstKey before inferring client pre command or after MOVE error.
So, in addition to that, the EVAL && EVALSHA modules has this declaration for the function to use.
While the function is:
So, in essence what happens is that the
evalFirstKeyIndex
gets options as a list and it does not having a keys object in it. maybe the second item in the list will have. as in the scope of theextractFirstKey
fn the originalArgs is actualy the input of original evalSha call.It causes the client to get undefined as firstKey so providing firstKey has no effect at all and then when running lua scripts you cannot provide hash keys to begin with which might cause unexpected errors and unresolvable failures.
I solved it in a dirty way just as a POC, I modified in EVALSHA module which is located in:
This change:
And it seem to solve the issue
Node.js Version
v20.11.0
Redis Server Version
7.2.2
Node Redis Version
redis@4.6.7
Platform
Linux
Logs
No response