Terraform-provider-aws: SNS Topic Resubscriptions don't retain RawMessageDelivery = True

[rkjackson]

Terraform Version

• Terraform v0.10.8
• provider.aws v1.2.0

Affected Resource(s)

• aws_sns_topic_subscription

Terraform Configuration Files

# Apply this configuration first
provider "aws" {
  region = "us-west-2"
}

resource "aws_sns_topic" "sns-topic" {
  name = "topicNameOne"
}

resource "aws_sqs_queue" "sqs-queue" {
  name = "sqsQueue"
}

resource "aws_sns_topic_subscription" "sns-topic" {
  topic_arn            = "${aws_sns_topic.sns-topic.arn}"
  protocol             = "sqs"
  endpoint             = "${aws_sqs_queue.sqs-queue.arn}"
  raw_message_delivery = true
}

# Apply this configuration second
# Note the changed sns-topic resource name
provider "aws" {
  region = "us-west-2"
}

resource "aws_sns_topic" "sns-topic" {
  name = "topicNameTwo"
}

resource "aws_sqs_queue" "sqs-queue" {
  name = "sqsQueue"
}

resource "aws_sns_topic_subscription" "sns-topic" {
  topic_arn            = "${aws_sns_topic.sns-topic.arn}"
  protocol             = "sqs"
  endpoint             = "${aws_sqs_queue.sqs-queue.arn}"
  raw_message_delivery = true
}

Debug Output

https://gist.github.com/rkjackson/44739a1fc5be04ef843d31f867dd0971

Expected Behavior

• After applying first configuration file, all resources are created successfully
• After applying second configuration file, newly named topic is created, with SQS Subscription and RawMessageDelivery = true

Actual Behavior

• After applying first configuration file, all resources are created successfully
• After applying second configuration file, newly named topic is created, with SQS Subscription and RawMessageDelivery = false

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply first configuration file
2. terraform apply second configuration file

[rkjackson]

In resourceAwsSnsTopicSubscriptionUpdate, there are many changes that can trigger the destruction of the previous topic subscription, and creation of a new one - this destruction also deletes (on the AWS side) any subscription attributes (in this case, RawMessageDelivery) as they are now orphaned.

https://github.com/terraform-providers/terraform-provider-aws/blob/93b7cbc152191361e589a3683fcc80ba1c3c6213/aws/resource_aws_sns_topic_subscription.go#L108-L123

However, resourceAwsSnsTopicSubscriptionUpdate only creates subscription attributes if d.HasChange is truthy. In the case of a changed topic name (which would result in a change to topic_arn, and thus a resubscription), the new and old state of raw_message_delivery remains true (indicating no change), thus the subscription attribute never gets set for the new subscription.

https://github.com/terraform-providers/terraform-provider-aws/blob/93b7cbc152191361e589a3683fcc80ba1c3c6213/aws/resource_aws_sns_topic_subscription.go#L125-L144

[bflad]

Hi folks! It turns out I likely "fixed" this in #2967 (switching re-subscriptions from using the update logic to delete/create logic to prevent some Terraform crashes). It was released in v1.7.1 of the AWS provider. Can someone double check if this is still an issue or not on v1.7.1 or higher of the provider please? Thanks!

[rkjackson]

Confirmed reproduction steps with v1.7.1 resulted in expected behavior.

[bflad]

Thanks so much for confirming! I'll close out this issue, but please let us know if you have any more trouble with this.

[ben-watt-es]

I ran into this issue yesterday, using whatever the latest version of the provider was at the time (probably 1.8.0).

I created a new SNS topic to replace another one, so all my SQS queues had to be resubscribed as the ARN updated.

resource "aws_sns_topic_subscription" "sub" {
  topic_arn            = "${data.terraform_remote_state.sns.sns_arn}"
  protocol             = "sqs"
  endpoint             = "${aws_sqs_queue.service.arn}"
  raw_message_delivery = true
}

I had to set it to false, apply, set to true then re-apply before the desired config was in place.

[hashibot[bot]]

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!