-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Check if error is retryable before returning that it is #1934
Conversation
Also, this probably needs a test. Is the accepted way there to just write an acceptance test and push it and see if it works? I don't have an Azure account that I can/am allowed to run them on. |
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.
Hi @carlpett,
Thank you for this fix. Might I suggest we move this to the utils/response package and create a new function ResponseErrorIsRetryable
? I would also combine the switch and function here into this new call.
if err != nil {
if utils.ResponseErrorIsRetryable(err) {
return resource.RetryableError(err)
} else {
return resource.NonRetryableError(err)
}
}
What do you think?
Sure! I mostly threw it together without having too much insights into the repo at large, your suggestions look very good. Will push an update soon! |
Once the PR LGTM (or almost does) I will run the acceptance test internally for the entire resource. If you write an acceptance test it will be verified at that time. |
608c49a
to
b3ae5f9
Compare
Pushed the implementation of your suggestions. I also noticed that |
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.
Thanks for the updates @carlpett, LGTM 👍
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks! |
Fixes #1757.
This PR checks if errors returned in
resource_arm_role_assignment
are actually retryable, rather than always retrying. If the approach is ok, it should also be applied toresource_arm_storage_container
, which uses the same "always retry" logic.Currently, I just check if the error (or nested error) is a
*url.Error
and if so if it is a temporary or timeout error. Anything else is deemed non-retryable. Are there other cases that should be retried?