Applying a plan with SQS queue with attributes matching an existing queue results in an import not a creation.

[opetch]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v0.12.13
+ provider.aws v2.35.0

Affected Resource(s)

aws_sqs_queue

Terraform Configuration Files

resource "aws_sqs_queue" "queue" {
  name = "my-queue" # a static name not one with a prefix or suffix made unique by variable interpolation 
}

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

aws_sqs_queue.queue: Creating...
aws_sqs_queue.queue: Creation complete after 1s [id=https://sqs.eu-west-1.amazonaws.com/[redacted]/my-queue]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

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

1. Reference (via modules) or copy above code into two root modules
2. run terraform apply in the first root module directory
3. run terraform apply in the second root module directory

Alternatively 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...

QueueAlreadyExists
A queue with this name already exists. Amazon SQS returns this error only if the request includes attributes whose values differ from those of the existing queue.
HTTP Status Code: 400
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html

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.

[naps62]

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:
I was trying to create a dead-letter queue for an already existing queue. Accidentally, I copied the resource block, and forgot to change the name. After I saw what I did, but still hadn't fully understood what happened, I destroyed the newly created resource, which of course, deleted the original queue.
For this reason, I'd consider this a possibly dangerous behaviour

[bflad]

Related: #14394

[ewbankkit]

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.

[github-actions]

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.