I can explain the observed problem - I'm not sure where the real problem lies or what the fix is.
The observed problem is that the Connect/Express RedisStore session store listens to redis-client 'error' events and assumes that an error means the connection is down - and marks the RedisStore as not ready (ie it stops working). Given a normal redis connection, that doesnt appear to be a bad assumption.
However, I pass in a haredis connection - which emits all errors of any of its nodes. A node error might just mean that 1 node (out of any number) is down.... which is not really an error per se - but thats not the way that the connect RedisStore sees it...
Not sure what the fix is.
Should the haredis connection only emit error when no nodes are left? (perhaps emit the node errors on a different channel - e.g. node-error?
I can explain the observed problem - I'm not sure where the real problem lies or what the fix is.
The observed problem is that the Connect/Express RedisStore session store listens to redis-client 'error' events and assumes that an error means the connection is down - and marks the RedisStore as not ready (ie it stops working). Given a normal redis connection, that doesnt appear to be a bad assumption.
However, I pass in a haredis connection - which emits all errors of any of its nodes. A node error might just mean that 1 node (out of any number) is down.... which is not really an error per se - but thats not the way that the connect RedisStore sees it...
Not sure what the fix is. Should the haredis connection only emit error when no nodes are left? (perhaps emit the node errors on a different channel - e.g. node-error?