-
Notifications
You must be signed in to change notification settings - Fork 62
New error message handling is broken when using sentinels #182
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
Comments
FYI @stanhu |
Is the simplest solution here to catch |
Alternatively, we could use a different method or use an argument to |
@stanhu IMO catching errors in |
I don't like the rescue idea, I think we should just not call anything that could fail from here. So we probably need a version of |
@stanhu if you want to fix it it's all good, but if you don't have time let me know and I'll find the time. |
@casperisfine I'll fix this. |
The issue is that |
redis-rb#178 introduced a regression that caused a ConnectionError to be thrown to the caller if the Sentinel master or replica could not be resolved. When a ConnectionError is thrown, the error message handler would attempt to retrieve `config.server_url`, but this in turn causes another Sentinel resolution to be attempted. We avoid this by adding a `resolved?` method that will indicate whether the config can be used. The error handler won't attempt to provide more details if the config has yet to be resolved. Closes redis-rb#182
redis-rb#178 introduced a regression that caused a ConnectionError to be thrown to the caller if the Sentinel master or replica could not be resolved. When a ConnectionError is thrown, the error message handler would attempt to retrieve `config.server_url`, but this in turn causes another Sentinel resolution to be attempted. We avoid this by adding a `resolved?` method that will indicate whether the config can be used. The error handler won't attempt to provide more details if the config has yet to be resolved. Closes redis-rb#182
redis-rb#178 introduced a regression that caused a `ConnectionError` to be thrown to the caller if the Sentinel master or replica could not be resolved. When a `ConnectionError` is thrown, the error message handler would attempt to retrieve `config.server_url`, but this in turn causes another Sentinel resolution to be attempted. We avoid this by adding a `resolved?` method that will indicate whether the config can be used. The error handler won't attempt to provide more details if the config has yet to be resolved. Closes redis-rb#182
I think #183 should solve this. |
It looks like this was fixed in v0.21.1. Thanks for the quick review and release! |
Release 0.21.0 introduced a new error message handling: #178
However, this blocks the execution when trying to connect to an invalid sentinel client. Check this example:
When using
0.20.0
. This is the result:And this is the result using
0.21.0
:After taking a quick look at the code, I'd say this happens because the new
HasConfig#message
method calls toconfig.server_url
:redis-client/lib/redis_client.rb
Lines 87 to 91 in 93c343a
Which calls to
host
:redis-client/lib/redis_client/config.rb
Lines 125 to 138 in 93c343a
Which, if I'm not wrong, ends up calling to
resolve_master
, and trying to connect again, thus raising the error again.redis-client/lib/redis_client/sentinel_config.rb
Lines 138 to 151 in 93c343a
The text was updated successfully, but these errors were encountered: