Leibale Eidelman

I just tried connecting to a cluster locally and it seems like it works.. I'm not sure what the bug is, and without being able to reproduce it we won't...

From the error stack trace it seems like the error is coming from ioredis (and not node-redis).. If you want we can debug this together, just ping me on the...

I just ran this script: ```javascript import { createClient } from 'redis'; await createClient({ host: '127.0.0.1', port: 6379 }) .on('error', err => console.error(err)) .on('connect', () => console.log('connected')) .connect(); ``` and...

@sjpotter if this is the intended behavior - we should not change/"hide" it on the client side.. but I don't think it is since there is nothing the user can...

IMO a better solution would be to run "rediscover" proactively when a connection dies rather than having a "slots refresh interval" (which will solve the problem eventually, but will still...

`ZINCRBY` only supports incrementing 1 key at a time, but you can wrap multiple of them with `MULTI` & `EXEC`: ```javascript await client.multi() .zIncrBy('key', 1, '1') .zIncrBy('key', 2, '2') .exec()...

I'll need to debug a bit more, but for now I'll at least explain what should happen: node-redis have 2 queues: waiting to be sent, and waiting for reply. When...

@puchm 1. until we fix it you can use `client.sendCommand` to workaround it: ```javascript const reply = await client.sendCommand(['ZADD', 'key', 'NX', '1', 'member']); ``` 2. there are 2 ways to...

Option 1 can be considered a bug fix, option 2 is a breaking change for sure. Should we do 1 for v4, and 2 for v5?

@puchm the main reason is to simplify the "main case", i.e: ```javascript const reply = await client.zAdd('key', { member: 'a', score: 1 }); ``` if NX, XX, LT, and GT...