-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
Race condition when creating kms key alias leads to 'Resource x does not have attribute y for variable' #6560
Comments
… after creation due to eventual consistency References: * #7891 * #6560 * #7873 * hashicorp/terraform#17220 The KMS service has eventual consistency considerations and the `aws_kms_alias` resource immediately tries to read the KMS alias after creation, which may not find the KMS alias. When not able to find the KMS alias, the resource logic returns an empty API object instead of an error. Since a `nil` check was already performed on the error, the error will always be `nil`. Invoking `return resource.RetryableError(nil)` is equivalent to `return nil`. The resource during its Read performs an error check first which will skip because its `nil`, then assumes the resource has been deleted outside Terraform and triggers recreation. Here when we cannot find a KMS alias after allowing some time for eventual consistency, we return a resource not found error and ensure we handle any timeouts due to automatic AWS Go SDK retries. Output from acceptance testing: ``` --- PASS: TestAccAWSKmsAlias_no_name (37.63s) --- PASS: TestAccAWSKmsAlias_name_prefix (37.80s) --- PASS: TestAccAWSKmsAlias_multiple (38.38s) --- PASS: TestAccAWSKmsAlias_importBasic (40.13s) --- PASS: TestAccAWSKmsAlias_ArnDiffSuppress (43.61s) --- PASS: TestAccAWSKmsAlias_basic (46.76s) ```
Fix submitted: #7907 |
… after creation due to eventual consistency (#7907) References: * #7891 * #6560 * #7873 * hashicorp/terraform#17220 The KMS service has eventual consistency considerations and the `aws_kms_alias` resource immediately tries to read the KMS alias after creation, which may not find the KMS alias. When not able to find the KMS alias, the resource logic returns an empty API object instead of an error. Since a `nil` check was already performed on the error, the error will always be `nil`. Invoking `return resource.RetryableError(nil)` is equivalent to `return nil`. The resource during its Read performs an error check first which will skip because its `nil`, then assumes the resource has been deleted outside Terraform and triggers recreation. Here when we cannot find a KMS alias after allowing some time for eventual consistency, we return a resource not found error and ensure we handle any timeouts due to automatic AWS Go SDK retries. Output from acceptance testing: ``` --- PASS: TestAccAWSKmsAlias_no_name (37.63s) --- PASS: TestAccAWSKmsAlias_name_prefix (37.80s) --- PASS: TestAccAWSKmsAlias_multiple (38.38s) --- PASS: TestAccAWSKmsAlias_importBasic (40.13s) --- PASS: TestAccAWSKmsAlias_ArnDiffSuppress (43.61s) --- PASS: TestAccAWSKmsAlias_basic (46.76s) ```
The fix has been merged and will release with version 2.2.0 of the Terraform AWS Provider, likely later today. |
This has been released in version 2.2.0 of the Terraform 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! |
Community Note
Terraform Version
Aws Provider Version
Affected Resource(s)
Debug Output
Expected Behaviour
Terraform should have waited for the kms alias to be created
Actual Behaviour
Steps to Reproduce
This is hard to reproduce as it is not consistently happening. We believe there is a race condition between terraform requesting the list of aliases and aws confirming alias creation
The text was updated successfully, but these errors were encountered: