difference Between multi.promise.exec() and multi.exec() in ioredis

[0Ams]

I am currently using Redis with multi.exec(), but I noticed that the result format differs when using multi.promise.exec().

multi.promise.exec() appears to support Bluebird promises, but the returned result format is different from multi.exec().
I expected both to return the same output, but there seems to be a difference.
Since I primarily want to use multi.exec(), I’d like to understand whether this difference is intentional and if there’s a recommended approach to ensure consistency.

Would appreciate any insights on this

const multi = redis.multi();
multi.zrevrank(key, id);
multi.hget(key, id);
const result1 = await multi.promise.exec() // [null, null]

const multi2 = redis.multi();
multi2.zrevrank(key, id);
multi2.hget(key, id);
const result = await multi.exec(); // [[null, null], [null, null]]

[dmaier-redislabs]

Hi Eddie,

it seems you are getting null values back. Could you try to execute this against data and let me know if the result still differs. If it does, please do the following:

1. Use redis-cli on the Redis instance against which you want to execute the transaction
2. Execute MONITOR and keep it open
3. Run the multi-exec without a promise and note the commands down that the server received.
4. Run the second multi-exec with the promise and note the commands down.

Does Redis in both cases receive the same sequence of commands?

Regards,
David

[0Ams]

Hi @dmaier-redislabs,
I tested it as you suggested, and the logs from MONITOR were identical. However, the returned results were different.
Both key and key2 used in the test did not exist in Redis, and I observed the same behavior when using the same keys.
The Redis version is 7.4.0, and I am using ioredis 5.6.0.

Test Code

    async test(redis) {
        const key = 'TEST_TEST_TEST_TEST';
        const id = 'id';
        const multi = redis.multi();
        multi.get(key);
        multi.hgetall(key);
        multi.hget(key, id);
        const result = await multi.promise.exec();
        console.log(`🚀 ~ test ~ result:`, result);

        const key2 = 'TEST_TEST_TEST_TEST2';
        const id2 = 'id2';
        const multi2 = redis.multi();
        multi2.get(key2);
        multi2.hgetall(key2);
        multi2.hget(key2, id2);
        const result2 = await multi2.exec();
        console.log(`🚀 ~ test ~ result2:`, result2);
    }

Output

🚀 ~ test ~ result: [ null, {}, null ]
🚀 ~ test ~ result2: [ [ null, null ], [ null, {} ], [ null, null ] ]

REDIS MONITOR

1741606658.603023 [0 127.0.0.1:49255] "multi"
1741606658.603064 [0 127.0.0.1:49255] "get" "TEST_TEST_TEST_TEST"
1741606658.603072 [0 127.0.0.1:49255] "hgetall" "TEST_TEST_TEST_TEST"
1741606658.603079 [0 127.0.0.1:49255] "hget" "TEST_TEST_TEST_TEST" "id"
1741606658.603086 [0 127.0.0.1:49255] "exec"
1741606658.608287 [0 127.0.0.1:49255] "multi"
1741606658.608314 [0 127.0.0.1:49255] "get" "TEST_TEST_TEST_TEST2"
1741606658.608318 [0 127.0.0.1:49255] "hgetall" "TEST_TEST_TEST_TEST2"
1741606658.608321 [0 127.0.0.1:49255] "hget" "TEST_TEST_TEST_TEST2" "id2"
1741606658.608325 [0 127.0.0.1:49255] "exec"

[dmaier-redislabs]

OK, might be a function of how arrays with null values in them are handled. I will take a look later this week. How critical is this issue for you?

[0Ams]

previously, we had been using redis.promise.xx. Recently, we attempted to remove .promise. and encountered this issue.
for us to fully transition away from .promise. and use async/await functions, the results should remain consistent regardless of whether .promise. is used.

while we can continue using the existing functions as they are, we would appreciate it if this issue could be considered.

Thanks 😄

[0Ams]

How is the progress regarding this bug going?

[IswaryaS]

Since there is a 'help wanted' label, I looked into this. Seems like there is intentionally a function to wrap the multi results in such a way so that the output is [[null, res]] instead of just [res] which indicates there is some usage dependent on this output format, and also probably consumed in this current form by consumers so a change to this (though minor, as just this function needs to be updated) would affect whoever is relying on this. I'll wait for @dmaier-redislabs to get back on this. If a change is approved, I'd be happy to raise a PR for it.