-
Notifications
You must be signed in to change notification settings - Fork 24.6k
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
Handle failure to retrieve ILM policy step better #49193
Conversation
This commit wraps the calls to retrieve the current step in a try/catch so that the exception does not bubble up. Instead, step info is added containing the exception to the existing step. Semi-related to #49128
Pinging @elastic/es-core-features (:Core/Features/ILM+SLM) |
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 this generally looks good, but I am wondering if we need a special error handling in this particular case (policy missing/invalid step) or if we should instead use our existing execution halting and error reporting mechanism and move the lifecycle state into the ERROR
step (ie. moveToErrorStep
) ? A note on this is that these are the cases where the policy does exist. The case where it does not is handled separately by updating just the step info. @gwbrown what do you think?
We can’t actually move to the error step because it requires being able to
parse the policy correctly, in some/most cases though, the error is because
the policy couldn’t be parsed. That’s why I went with the step info rather
than ERROR step.
On Mon, Nov 18, 2019 at 4:17 AM Andrei Dan ***@***.***> wrote:
***@***.**** commented on this pull request.
I think this generally looks good, but I am wondering if we need a special
error handling in this particular case (policy missing/invalid step) or if
we should instead use our existing execution halting and error reporting
mechanism and move the lifecycle state into the ERROR step (ie.
moveToErrorStep) ? @gwbrown <https://github.com/gwbrown> what do you
think?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#49193?email_source=notifications&email_token=AAAEU5BO3BAU3HKVWIJKZQTQUJ2TJA5CNFSM4JN6HZUKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCL4DZ7Y#pullrequestreview-318258431>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAEU5AQ2ARQ3U74OR42Y63QUJ2TJANCNFSM4JN6HZUA>
.
|
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.
LGTM
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.
LGTM as well. I would like it if we could signal the error the same way as other policy errors as well, but I'm in favor of more visibility here as an improvement over the current situation since that's nontrivial.
We will not backport this to 7.4 as a 7.5 release is imminent and there'll likely be no more 7.4.x releases |
This commit wraps the calls to retrieve the current step in a try/catch so that the exception does not bubble up. Instead, step info is added containing the exception to the existing step. Semi-related to elastic#49128 (cherry picked from commit 72530f8) Signed-off-by: Andrei Dan <andrei.dan@elastic.co>
This commit wraps the calls to retrieve the current step in a try/catch so that the exception does not bubble up. Instead, step info is added containing the exception to the existing step. Semi-related to elastic#49128 (cherry picked from commit 72530f8) Signed-off-by: Andrei Dan <andrei.dan@elastic.co>
This commit wraps the calls to retrieve the current step in a try/catch
so that the exception does not bubble up. Instead, step info is added
containing the exception to the existing step.
Semi-related to #49128