awscc_chatbot_slack_channel_configuration always tries to update customization_resource_arns even after applying

[cswilliams]

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 other comments that do not add relevant new information or questions, 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
• The resources and data sources in this provider are generated from the CloudFormation schema, so they can only support the actions that the underlying schema supports. For this reason submitted bugs should be limited to defects in the generation and runtime code of the provider. Customizing behavior of the resource, or noting a gap in behavior are not valid bugs and should be submitted as enhancements to AWS via the CloudFormation Open Coverage Roadmap.

Terraform CLI and Terraform AWS Cloud Control Provider Version

Affected Resource(s)

• awscc_chatbot_slack_channel_configuration

Terraform Configuration Files

resource "awscc_chatbot_slack_channel_configuration" "slack_channel" {
  configuration_name = var.slack_channel_name
  guardrail_policies = [
    "arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess"
  ]
  iam_role_arn       = aws_iam_role.slack_chatbot.arn
  user_role_required = false
  slack_channel_id   = var.slack_channel_id
  slack_workspace_id = var.slack_workspace_id
  sns_topic_arns     = var.sns_topic_arns

  tags = [{
    key   = "Name"
    value = var.slack_channel_name
  }]
}

Debug Output

Terraform always tries to apply the following, even after applying:

Terraform will perform the following actions:

  # module.xxxxx.awscc_chatbot_slack_channel_configuration.slack_channel will be updated in-place
  ~ resource "awscc_chatbot_slack_channel_configuration" "slack_channel" {
      + customization_resource_arns = (known after apply)
        id                          = "arn:aws:chatbot::XXXXXXX:chat-configuration/slack-channel/app-alerts-core-staging"
        tags                        = [
            {
                key   = "Name"
                value = "xxx-xxxxxxx"
            },
        ]
        # (9 unchanged attributes hidden)
    }

In my tfstate file I see this change for the resource:

 "customization_resource_arns": null,

Expected Behavior

It should not keep prompting to apply this even after applying.

Actual Behavior

It keeps prompting to apply this change even after applying.

Steps to Reproduce

Versions:
awscc: 1.22.0
aws: 5.80.0
terraform: 1.10.1

1. terraform apply

Important Factoids

• This issue appeared after upgrading awscc from 1.20.0 to 1.22.0
• I've tried deleting the resource from my state and reimporting using terraform import but that had no affect.

References

[quixoticmonk]

Thank you for opening the issue @cswilliams . I tried to reproduce this on my end and couldn't. Can you review if there is anything else on your configuration different from mine which is causing this ? ( maybe more sns topics than one ?)

I started off from v1.20.0 and deployed the infra and upgraded my awscc provider to 1.23.0 and did a tf apply again.

resource "awscc_chatbot_slack_channel_configuration" "slack_channel" {
  configuration_name = "example"
  guardrail_policies = [
    "arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess"
  ]
  iam_role_arn       = awscc_iam_role.example.arn
  user_role_required = false
  slack_channel_id   = "abc"
  slack_workspace_id = "abc"
  sns_topic_arns     = ["arn:aws:sns:us-east-1:####:test"]

    tags = [{
    key   = "Name"
    value = "example"
  }]

}

resource "awscc_iam_role" "example" {
  role_name = "ChatBot-Channel-Role"
  assume_role_policy_document = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = ""
        Principal = {
          Service = "chatbot.amazonaws.com"
        }
      },
    ]
  })
  managed_policy_arns = ["arn:aws:iam::aws:policy/AWSResourceExplorerReadOnlyAccess"]
}

[cswilliams]

Sure, will try to provide more info. So I have an awscc_chatbot_slack_channel_configuration with two sns topics, one topic is in us-east-1 and the other topic is in us-east-2. My provider region is us-east-2.

I have a module which creates this awscc_chatbot_slack_channel_configuration in several different AWS accounts. I was noticing in one of my staging accounts, I end up creating two awscc_chatbot_slack_channel_configuration but only one of them has the bug. Here's the excerpt of the resource in my tfstate that has the bug:

 {
      "module": "module.app_core_staging.module.app_alerts_slack_channel[0]",
      "mode": "managed",
      "type": "awscc_chatbot_slack_channel_configuration",
      "name": "slack_channel",
      "provider": "provider[\"registry.terraform.io/hashicorp/awscc\"]",
      "instances": [
        {
          "schema_version": 1,
          "attributes": {
            "arn": "arn:aws:chatbot::XXXXXXXXXXX:chat-configuration/slack-channel/app-alerts-core-staging",
            "configuration_name": "app-alerts-core-staging",
            "customization_resource_arns": null,
            "guardrail_policies": [
              "arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess"
            ],
            "iam_role_arn": "arn:aws:iam::XXXXXXXXXXX:role/service-role/SlackChatbot-app-alerts-core-staging",
            "id": "arn:aws:chatbot::XXXXXXXXXXX:chat-configuration/slack-channel/app-alerts-core-staging",
            "logging_level": "NONE",
            "slack_channel_id": "XXXXXXXXXXX",
            "slack_workspace_id": "XXXXXXXXXXX",
            "sns_topic_arns": [
              "arn:aws:sns:us-east-1:XXXXXXXXXXX:CoreSlackAlerts",
              "arn:aws:sns:us-east-2:XXXXXXXXXXX:CoreSlackAlerts"
            ],
            "tags": [
              {
                "key": "Name",
                "value": "app-alerts-core-staging"
              }
            ],
            "user_role_required": false
          },
          "sensitive_attributes": [],
          "dependencies": [
            "module.app_core_staging.module.app_alerts_slack_channel.aws_iam_role.slack_chatbot",
            "module.app_core_staging.module.app_alerts_slack_channel.data.aws_iam_policy_document.chatbot_assume_role_policy",
            "module.app_core_staging.module.global_slack_alerts_topic.aws_sns_topic.topic",
            "module.app_core_staging.module.slack_alerts_topic.aws_sns_topic.topic"
          ]
        }
      ]
    },

Here's a similar resource from the same account that doesn't have the bug:

   {
          "module": "module.devops_alerts_slack_channel",
          "mode": "managed",
          "type": "awscc_chatbot_slack_channel_configuration",
          "name": "slack_channel",
          "provider": "provider[\"registry.terraform.io/hashicorp/awscc\"]",
          "instances": [
            {
              "schema_version": 1,
              "attributes": {
                "arn": "arn:aws:chatbot::XXXXXXXXXXX:chat-configuration/slack-channel/devops-alerts-core-staging",
                "configuration_name": "devops-alerts-core-staging",
                "customization_resource_arns": null,
                "guardrail_policies": [
                  "arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess"
                ],
                "iam_role_arn": "arn:aws:iam::XXXXXXXXXXX:role/service-role/SlackChatbot-devops-alerts-core-staging",
                "id": "arn:aws:chatbot::XXXXXXXXXXX:chat-configuration/slack-channel/devops-alerts-core-staging",
                "logging_level": "NONE",
                "slack_channel_id": "XXXXXXXXXXX",
                "slack_workspace_id": "XXXXXXXXXXX",
                "sns_topic_arns": [
                  "arn:aws:sns:us-east-2:XXXXXXXXXXX:DevOpsSlackAlerts",
                  "arn:aws:sns:us-east-1:XXXXXXXXXXX:DevOpsSlackAlerts"
                ],
                "tags": [
                  {
                    "key": "Name",
                    "value": "devops-alerts-core-staging"
                  }
                ],
                "user_role_required": false
              },
              "sensitive_attributes": [],
              "dependencies": [
                "data.aws_caller_identity.current",
                "module.devops_alerts_slack_channel.aws_iam_role.slack_chatbot",
                "module.devops_alerts_slack_channel.data.aws_iam_policy_document.chatbot_assume_role_policy",
                "module.devops_slack_alerts_topic.aws_sns_topic.topic",
                "module.global_devops_slack_alerts_topic.aws_sns_topic.topic"
              ]
            }
          ]
        },

One difference between the two that I could see is that the one with the bug has the us-east-1 SNS topic listed first.

I have a production AWS account which creates two identical resources to the above and in that account, both my app_alerts and devops_alerts resources suffer from the bug and both have the us-east-1 SNS topic listed first.

So I wonder if it might have something to do with an sns topic in another region being listed first? Really strange though.

I have some other AWS accounts where i'm creating awscc_chatbot_slack_channel_configuration but only using one SNS topic in us-east-2 and these don't suffer from the bug either.

I'll also mention that the bug appeared in 1.22.0. When I downgrade to 1.21.0, it goes away. The bug also still exists in 1.23.0.

If there's anything else I can provide, lemme know.

[cswilliams]

I just tried 1.26.0 to see if this issue still exists in the latest version, but unfortunately I'm still hitting the same problem, so still stuck on 1.21.0 for now.

[cswilliams]

Sorry, I must have accidentally clicked the closed button when I commented last. I did not mean to close this issue.

I had some time today to dig into this since it's preventing me from upgrading to the latest awscc versions. I built the provider locally and then ran a git bisect. I found the offending commit is: 6355330

I'm guessing adding the CustomizationResourceArns to the AWS_Chatbot_SlackChannelConfiguration.json started the problem.

At any rate, after much trial and error, I discovered that this issue appears to be caused by the sns_topic_arns being provided to awscc_chatbot_slack_channel_configuration in the "wrong" order. When I updated the order of sns_topic_arns to match the order returned by the cloudcontrol list-resources call, then terraform no longer tried to apply the customization_resource_arns change over and over.

I'm unsure what governs the order, but it doesn't appear to be based on the order provided when you create the channel configuration. I have multiple AWS accounts managed with the same exact terraform module, slack configuration, and sns topics and the order is different across accounts. Adding/removing SNS topics in a different order or recreating the entire channel configuration also does not change the order (at least in my tests).

It's strange to me though that adding the customization_resource_arns would cause this issue. Previous to that change, terraform did not care about the order the sns topics were defined in.

It would definitely be nice if the old behavior could be restored so that the order does not matter. I could see people hitting this bug if they create a channel configuration and then the api chooses to return the sns topics in a different order that what is defined in their awscc_chatbot_slack_channel_configuration resource.