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

builtin: Refactor resource.Retry to clarify return #5543

Merged
merged 1 commit into from
Mar 10, 2016

Conversation

phinze
Copy link
Contributor

@phinze phinze commented Mar 9, 2016

Change the RetryFunc from a plain error return type to a
specialized RetryError which must decide whether it is
retryable or not.

Add RetryableError / NonRetryableError factory functions that
callers are meant to use to build up these errors.

This makes it eminently clear whether or not a given error is
retryable from inside the client code.

Goal here is to not change any behavior, simply reflect the
existing behavior with the new, clearer, API.

@phinze phinze force-pushed the phinze/retryerror-pointers-are-evil branch from e5ac704 to c52aee7 Compare March 9, 2016 22:59
@phinze phinze force-pushed the phinze/retryerror-pointers-are-evil branch from c52aee7 to 5cb5927 Compare March 9, 2016 23:17
@@ -273,7 +276,8 @@ func resourceAwsLambdaPermissionDelete(d *schema.ResourceData, meta interface{})
policy := LambdaPolicy{}
err = json.Unmarshal(policyInBytes, &policy)
if err != nil {
return fmt.Errorf("Error unmarshalling Lambda policy: %s", err)
return resource.RetryableError(
fmt.Errorf("Error unmarshalling Lambda policy: %s", err))
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here's a good example of something that probably should be NonRetryable but I left because I wanted this to be purely a refactor.

@phinze phinze force-pushed the phinze/retryerror-pointers-are-evil branch from 5cb5927 to 529d067 Compare March 9, 2016 23:31
Change the `RetryFunc` from a plain `error` return type to a
specialized `RetryError` which must decide whether it is
retryable or not.

Add `RetryableError` / `NonRetryableError` factory functions that
callers are meant to use to build up these errors.

This makes it eminently clear whether or not a given error is
retryable from inside the client code.

Goal here is to _not_ change any behavior, simply reflect the
existing behavior with the new, clearer, API.
@phinze phinze force-pushed the phinze/retryerror-pointers-are-evil branch from 529d067 to 108ccf0 Compare March 9, 2016 23:38
@jen20
Copy link
Contributor

jen20 commented Mar 10, 2016

LGTM assuming we don't want to change behaviour here

phinze added a commit that referenced this pull request Mar 10, 2016
…e-evil

builtin: Refactor resource.Retry to clarify return
@phinze phinze merged commit f8c6781 into master Mar 10, 2016
@phinze phinze deleted the phinze/retryerror-pointers-are-evil branch March 10, 2016 00:15
@ghost
Copy link

ghost commented Apr 27, 2020

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants