-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
Applying a plan with SQS queue with attributes matching an existing queue results in an import not a creation. #10824
Comments
Just ran into this issue last night. I'd be insterested in working on this myself (I've been curious to know more about the terraform codebase anyway), but probably I'd need some pointers on where to look, or even know if this something accessible to someone not familiar with the codebase? For context, my story: |
Related: #14394 |
Hi @opetch👋 Thank you for submitting this and this is an excellent use case of somewhere that Terraform and the Terraform AWS Provider could be much more helpful since in many cases they have enough information to return an error upfront during planning instead of unexpected behavior during apply. I believe this falls under the provider-wide enhancement proposal of #14394, so by adding this link here it will add a reference to that issue so we can include it as a use case when thinking about the implementation details. Since this is likely something we will want more broadly across many resources, I'm going to close this particular issue to consolidate discussions, efforts, and prioritization on the topic while the reference would serve as the cue to make this specific resource one of the initial implementations. I would suggest those 👍 upvoting and subscribing here to do so on #14394 so we can appropriately gauge interest. Please feel free to provide feedback there. |
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. |
Community Note
Terraform Version
Affected Resource(s)
aws_sqs_queue
Terraform Configuration Files
Expected Behavior
Applying this terraform in two seperate root modules that exist within the same account and region should result in an error upon the second apply due to conflicts with the resource created in the first apply in relation to the uniqueness of the name attribute.
Actual Behavior
Terraform claims the resource has been created, yet it's actually just updated the state file with the details of the existing resource. This is effectively equivalent to a terraform import.
Steps to Reproduce
terraform apply
in the first root module directoryterraform apply
in the second root module directoryAlternatively step 2 could be replaced with a manual creation of the queue with same attributes & name. It does not matter how the initial queue was created, only that it exists when step 3 is executed.
Important Factoids
The reason this behaviour is observed is because the AWS API for SQS will only return a http status code of 400 for a CreateQueue request if the attributes of the requested queue do not match that of the existing. See the docs...
For this reason could be argued that this is not a bug, that is if the view is taken that the terraform provider should match the AWS API in behaviour. However I believe it is a bug as it's not what I expect to happen when I run terraform. If I run an apply and it completes, I believe terraform has created all the resources (in that particular invocation) that were listed in the plan and if I then run destroy I should not need to worry that something created by someone else previously could be affected.
The text was updated successfully, but these errors were encountered: