The default retry strategy:
var client = redis.createClient({
retry_strategy: function (options) {
if (options.error.code === 'ECONNREFUSED') {
// End reconnecting on a specific error and flush all commands with a individual error
return new Error('The server refused the connection');
}
...
// reconnect after
return Math.max(options.attempt * 100, 3000);
}
});
Crashes since version 2.6.1
if (options.error.code === 'ECONNREFUSED')
^
TypeError: Cannot read property 'code' of null
I'm getting a similar issue, with or without the explicit retry_strategy.
I'm testing what happens to my server when the cache layer(redis) crashes or there is some sort of outage that prevents redis from working.
I found out that in this case, for every redis command I try to execute, the attached callback is not called. I expected to have the error handled correctly, but instead it seems to blatantly ignore the command.
Is this the expected behaviour or is it a bug?
@neslinesli93 your issue sounds like a different topic than the one from @elstonie. Would you be so kind and show me your code? There should be no case where the callback is not called.
@elstonie I'm aware of this and I'm going to check if I revert to the old behavior as soon as I find the time to look more closely at it.
@BridgeAR I forgot to mention that, to test this, I am not calling quit()
but I am killing redis service by hand.
As a result, node_redis keeps trying to reconnect again and again (which I guess it's expected behaviour), but callbacks are not executed.
This is an excerpt of my code:
redisClient.zrevrange([REDIS_KEYS.CHATS + city, 0, 5], function(error, replies) {
if (error) {
console.log(error);
executeQuery(db.query("SELECT * FROM $1~ ORDER BY uid DESC LIMIT 5", cityTable), false);
} else {
if (replies.length === 0) {
executeQuery(db.query("SELECT * FROM $1~ ORDER BY uid DESC LIMIT 5", cityTable), true);
} else {
res.send({ result: replies, parsed: false });
}
}
});
@neslinesli93 your commands land in the offline queue. node_redis tries to reconnect and buffers the command until it's connected again or until you stop reconnecting. Therefore the commands are not fired. If you want them to fail in such a case, please deactivate the offline queue.
@BridgeAR thank you, I solved the problem.
What I didn't know is that in order to make this work, I have to listen to error
event, or I get unhandled exceptions all over the place
I am having the same problem as @elstonie. The options
object doesn't contain any error
if connection to Redis was lost. That happens however only when trying to reconnect for the first time, following calls of retry_strategy
provide an error
.
I'm experiencing the same problem in 2.8.0 as Mattijah.
I think that it is a bug that options.error
is empty during the first failure. This doesn't let me to reason about the cause of the failure. I wanted to implement a logic that retries only when specific error happen - now I need to restart regardless of the options.error
as it may be empty during the first retry.