aws_lb_listener: wait for listener creation #5167
Conversation
AWS resources can take some time to appear in listings. When we created a listener before, it could happen that the creation succeeded but the listing of the resource right after creation would return a resource not found. This can me normal on AWS where changes can take some time to propagate. The correct behaviour in this case is to retry reading the resource until we find it (because we know that it has been created successfully). We don't change the behaviour on resource reads that are not following a creation where a resource not found is still going to remove the resource from the tfstate. This should fix hashicorp#2456
| ListenerArns: []*string{aws.String(d.Id())}, | ||
| } | ||
|
|
||
| err := resource.Retry(d.Timeout(schema.TimeoutRead), func() *resource.RetryError { |
There was a problem hiding this comment.
When dealing with AWS service eventual consistency, we prefer to hardcode 1 minute timeouts. Generally its not desired to allow that timeout to be user configurable as its a knob that is unlikely to handle the situation properly by waiting longer.
| @@ -25,6 +25,10 @@ func resourceAwsLbListener() *schema.Resource { | |||
| State: schema.ImportStatePassthrough, | |||
| }, | |||
|
|
|||
| Timeouts: &schema.ResourceTimeout{ | |||
There was a problem hiding this comment.
If we do decide to add user configurable timeouts for the resource (I would recommend against in this situation), it should be documented in the resource documentation under a ## Timeouts header.
bflad
added
bug
|
@mildred , many thanks for the fix, this particular bug is super nasty in my scenario, since I have tons of listeners and rules created and destroyed. Looking forward to get this merged |
|
+1 for getting this merged. I experience this on a daily basis |
bflad
removed
the
waiting-response
There was a problem hiding this comment.
PR feedback addressed in 1085a58 🚀
--- PASS: TestAccAWSLBListenerRule_multipleConditionThrowsError (1.79s)
--- PASS: TestAccAWSLBListener_basic (187.43s)
--- PASS: TestAccAWSLBListenerRule_fixedResponse (189.04s)
--- PASS: TestAccAWSLBListenerRule_redirect (197.55s)
--- PASS: TestAccAWSLBListener_cognito (201.62s)
--- PASS: TestAccAWSLBListener_oidc (207.87s)
--- PASS: TestAccAWSLBListenerRule_changeListenerRuleArnForcesNew (208.18s)
--- PASS: TestAccAWSLBListenerRule_oidc (209.59s)
--- PASS: TestAccAWSLBListenerRule_updateRulePriority (209.97s)
--- PASS: TestAccAWSLBListener_fixedResponse (210.71s)
--- PASS: TestAccAWSLBListener_https (211.47s)
--- PASS: TestAccAWSLBListener_redirect (220.32s)
--- PASS: TestAccAWSLBListenerRule_basic (225.98s)
--- PASS: TestAccAWSLBListenerRule_cognito (229.10s)
--- PASS: TestAccAWSLBListenerRule_priority (288.32s)
|
This has been released in version 1.40.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. |
|
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. Thanks! |
ghost
locked and limited conversation to collaborators
AWS resources can take some time to appear in listings. When we created
a listener before, it could happen that the creation succeeded but the
listing of the resource right after creation would return a resource not
found.
This can me normal on AWS where changes can take some time to propagate.
The correct behaviour in this case is to retry reading the resource
until we find it (because we know that it has been created
successfully).
We don't change the behaviour on resource reads that are not following a
creation where a resource not found is still going to remove the
resource from the tfstate.
This should fix #2456