-
Notifications
You must be signed in to change notification settings - Fork 337
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
Failsafe on Redis error replies in RedisCacheStoreProxy. #421
Failsafe on Redis error replies in RedisCacheStoreProxy. #421
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
To be consistent I guess you would also want to rescue #read
, right?
@grzuy thanks for reviewing this PR and sorry for coming back to you so late!
Not sure what you exactly mean here? |
Hi @cristiangreco, Sorry for my short and vague comment :-P So, rack-attack will eventually call Whether or not those methods are re-implemented on any particular proxy doesn't mean they aren't going to be called. In particular, for the If you don't re-implement an rescue |
@grzuy thanks for the thorough explanation! I've force pushed a change to wrap |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the update!
end | ||
end | ||
|
||
def read(name) | ||
rescuing { super(name) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we are overriding ActiveSupport::Cache::Store#read(name, options = nil)
, which potentially can receive two arguments.
What about going with the following?
def read(*_args)
rescuing { super }
end
So that we allow options
argument, plus we make it forward compatible with any arity changes to the original #read
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks sensible, I've updated it!
RedisCacheStoreProxy will blow up when RedisCacheStore raises a CommandError exception. In fact, by default the proxied store only handles BaseConnectionError exceptions, but will let bubble up any other type of exception from the underlying client. This pull request uses the same approach from RedisProxy, where store operations are wrapped in a `rescuing` block that rescues and ignores BaseError exceptions (the most generic exception class that can be raised by the Redis client).
Thank you! |
RedisCacheStoreProxy will blow up when RedisCacheStore raises a
CommandError exception. In fact, by default the proxied store only
handles BaseConnectionError exceptions, but will let bubble up any other
type of exception from the underlying client.
This pull request uses the same approach from RedisProxy, where store
operations are wrapped in a
rescuing
block that rescues and ignoresBaseError exceptions (the most generic exception class that can be
raised by the Redis client).
Best viewed ignoring whitespaces.