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

Fix: better (Redis) exception handling #89

Merged
merged 28 commits into from
May 3, 2021

Conversation

kares
Copy link
Contributor

@kares kares commented Apr 15, 2021

Redis doesn't wrap all of the errors e.g. (retriable) IOError might be raised from an IO write (#88).
With the refactored error handling we make sure these are logged and retried instead of causing pipeline crashes.

Also not all specs from the suite were run on the CI, as some are tagged with redis.
These require a real Redis server, no reason not to run them against CI as well.

NOTE: extracted from #87 except the problematic subscription 'interrupting' bits (which are still pending)

resolves #88

@kares kares marked this pull request as ready for review April 15, 2021 17:18
@kaisecheng kaisecheng self-requested a review April 15, 2021 22:47
Copy link
Contributor

@kaisecheng kaisecheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a comment for the method name.
Can you check the red CI?

Stud.stoppable_sleep(1) { stop? }
retry if !stop?
rescue => e
retry unless handle_error(e)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A suggestion to rename handle_error
I can understand you want to retry when handle_error cannot handle, meaning return false
Looking at the whole function, we actually want to retry when it is retryable error, somehow meaning we can handle it, so it is a bit confusing at the first look.

may be we can do retry handle_error(e) or retry retryable_error(e) ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, no super clear - also struggled a bit with naming here.
we're trying to re-use this method as much as possible.
so handle_error returns true if error is handled and should not be retried 😉

I guess you meant retry if handle_error(e),
that is actually what I started with but the inverse boolean condition confused someone else 🤣

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think retry unless handle_error is ok - another way you could possibly handle this is to just have the new method a no side effect logging method, like log_error(e), which just deals with the formatting/logging keeping the actual retry logic (with the ShutdownSignal special case) local

Copy link
Contributor Author

@kares kares May 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, split the method into two.
still needed some kind of retry if ... as the logic is at two places - did not want to have the same logic inline twice. esp. since looking at the plugin the first time I manage to miss the "other" error handling place initially.

let's see what @kaisecheng thinks 🤞

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is much better. Splitting to two is great 👏 . The naming and comment help a lot. Thanks for doing it.

Copy link
Contributor

@robbavey robbavey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor comments

end
else
@redis.disconnect!
redis.disconnect!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commit removes this comment:

 if its a SubscribedClient then:
    # it does not have a disconnect method (yet)

It feels like there is some context missing as to why disconnect! is not called when redis is subscribed, if this is indeed still the desired behaviour.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

believe this was a left over from the Redis 3.x days.
Redis#disconnect is always fine to call (in 4.x) regardless of the @client used (@original_client is never "replaced").

also no reason not to have disconnect (close) here, I've updated the PR - thanks for the hint.

Stud.stoppable_sleep(1) { stop? }
retry if !stop?
rescue => e
retry unless handle_error(e)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think retry unless handle_error is ok - another way you could possibly handle this is to just have the new method a no side effect logging method, like log_error(e), which just deals with the formatting/logging keeping the actual retry logic (with the ShutdownSignal special case) local

@kares kares requested a review from kaisecheng May 3, 2021 09:30
Copy link
Contributor

@kaisecheng kaisecheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🧚

Copy link
Contributor

@robbavey robbavey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kares kares merged commit 71d3ee5 into logstash-plugins:master May 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

handle generic (unwrapped) errors from Redis
5 participants