We're working on storing some ephemeral, nice-to -have data in a Kredis.ordered_set. During a recent game day where we intentionally took down our redis instance, I was a little surprised to see that some of the Kredis operations were fault-tolerant, but some weren't.
It looks like the current implementation uses method_missing to delegate methods from OrderedSet (and others) to the underlying redis proxy, but redis.multi is not wrapped in the failsafe. As a result, in the event of a redis connection failure, commands that are straightforwardly delegated to the underlying redis do not raise errors, but the same commands that wrapped in redis.multi do raise an error.
Now there are varying degrees of fault-tolerance, depending on the method you choose
Just to add, there was this comment explaining the intent to rethink how failsafe works. I'm watching the project to see if anything gets decided on that front.
We're working on storing some ephemeral, nice-to -have data in a
Kredis.ordered_set
. During a recent game day where we intentionally took down our redis instance, I was a little surprised to see that some of the Kredis operations were fault-tolerant, but some weren't.It looks like the current implementation uses
method_missing
to delegate methods fromOrderedSet
(and others) to the underlying redis proxy, butredis.multi
is not wrapped in the failsafe. As a result, in the event of a redis connection failure, commands that are straightforwardly delegated to the underlying redis do not raise errors, but the same commands that wrapped inredis.multi
do raise an error.Now there are varying degrees of fault-tolerance, depending on the method you choose
Is this the intended behaviour, or should Kredis operations be fault-tolerant by default?