retry_strategy doesn't reset after flushing the error

• Version: node_redis 2.6.5, redis 3.2.7
• Platform: Node.js 7.5.0 on Mac OS 10.12.3
• Description:

I’m using the following code

const redis = require('redis');

const client = redis.createClient({
  url: 'redis://localhost:6379',
  retry_strategy: options => new Error('Fail')
});

setInterval(() => client.incr('some-key', console.log), 5000);

running against a local redis (docker run --rm -p 6379:6379 redis)

After I see the first output, I kill the redis to simulate disconnect. When I’ve seen the error come in I restart the redis. The connection doesn’t come up again. I would expect that after flushing the error to the offline handlers, the client would try to reconnect on the next command. instead it stays in closed state. Also it’s returning with AbortError instead of new Error('Fail').

[newhouse]

Quick update here. I added the enable_offline_queue = false to my createClient options, and it seems to have done what I wanted it to, which is: “Continue to attempt to re-connect to my Redis server based on the retry_strategy function, but immediately throw errors in response to attempts to use the client in the meantime. Then, if able to reconnect, just start working again”.

FYI: Thows the following error on a get call: AbortError: SET can't be processed. Stream not writeable.

For my usage as a straight layer between the DB and my app, this should be fine. Would be nice to know if there’s a more “robust” solution possible where:

• Client continues to attempt to reconnect based on retry_strategy
• Calls/consumers/users of the Client don’t hang while it’s reconnecting
• Commands can still be queued (conditionally?) to be executed if/when a connection is re-established…in case I’m incrementing things, etc.

Probably a lot of tough scenarios to consider here…

[Janpot]

@BridgeAR It’s pretty much that right now, if redis connection breaks for some reason, all my commands just hang. Suppose I have a fallback for the operation that redis is doing then that fallback also hangs. I’d rather want redis to return an error after a few retries, which I can catch and employ the fallback. That doesn’t mean I don’t want the client to stop trying to connect. Redis might come back up in a minute.

I just don’t see the point of the current behavior. You return an error in the retry handler and then your client just dies forever. Who needs that sort of behavior unless you create a client for every command?

Or I might not see the use case for that ofcourse 😄