Simulate server unavailable? about miniredis HOT 11 CLOSED

See #158: I added SetError(), which can be used to set 'loading' errors and such. If you want connection errors would the existing Close() and Restart() work?

from miniredis.

Interesting idea. With ping you mean a TCP ping, or something which executes the redis PING command?

We could add a configurable delay in the server before accepting a new connection, or in the middle of the execution of a command (say put a time.Sleep here, which is after reading the command, but before executing it)

from miniredis.

Hi alicebob,

the idea is to have the ability to test your code against unexpected disconnects (e.g. cases where a dial tcp :6379: connect: connection refused error is returned).

For this reason it would be great, if you could "flip a switch" to tell miniredis to return above error for all calls.

from miniredis.

This is the original issue that made me create https://github.com/elliotchance/redismock. However, as @warijo says a switch to indicate that redis is unavailable would be helpful.

from miniredis.

It sounds useful and simple enough. Could either of you give some example methods how you would like miniredis to work? Just the method signatures should be enough.

from miniredis.

assuming
mr, _ := miniredis.Run()
how about
mr.SetIsConnected(false)
or
mr.ReturnConnectionError(true)

after that, I would expect all calls to miniredis (HGet, Hset, etc.) to return an error like the one I mentioned above

from miniredis.

I wasn't aware of the existence of those methods. As they already exist, I'm not sure how much sense it makes to wrap an additional SetError()-method around them. Maybe a short additional entry in the README on how to simulate server-unavailability would be enough?

One last thing: miniredis behaves a bit differently than the actual redis implementation regarding connection aborts. When I tested my productive service against connection aborts, I would get an EOF error, after the connection to redis had crashed. The reason seems to be that the connection is "broken" and needs to be removed from the connection pool. Check here for a discussion about this issue.

The solution was to set the MaxRetries parameter when initializing the redis client (I'm using go-redis/v7). In miniredis this behavior doesn't occur. When I call mr.Close(), followed by a mr.Restart() the next call to miniredis will work just fine, even without increasing MaxRetries. But I guess this is a rather difficult thing to implement.

from miniredis.

from miniredis.

from miniredis.

I just tried to reproduce it as well, and wasn't able to (I get the EOF now as well). My only guess is that I tested it with my implementation and forgot to remove the MaxRetries-param from the go-redis client. Sorry for wasting your time.

from miniredis.

from miniredis.