Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should Kredis::Types::Proxy#multi be fault tolerant? #153

Open
BigBlue79 opened this issue Jul 25, 2024 · 0 comments
Open

Should Kredis::Types::Proxy#multi be fault tolerant? #153

BigBlue79 opened this issue Jul 25, 2024 · 0 comments

Comments

@BigBlue79
Copy link

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

os = Kredis.ordered_set("testing")

os.elements
# => [] 

os.remove("something")
# => nil 

os.append("something")
# => Connection refused - connect(2) for 127.0.0.1:6379 (redis://localhost:6379) (Redis::CannotConnectError)

os.prepend("something")
# => Connection refused - connect(2) for 127.0.0.1:6379 (redis://localhost:6379) (Redis::CannotConnectError)

Is this the intended behaviour, or should Kredis operations be fault-tolerant by default?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant