awscc_dynamodb_table - unchanged configuration triggers drift on terraform plan

[wellsiau-aws]

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_dynamodb_table

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.

resource "awscc_dynamodb_table" "table_name" {
  table_name = "table-name"

  key_schema = jsonencode([{
    AttributeName : "id"
    KeyType : "HASH"
  }])
  attribute_definitions = [{
    attribute_name = "id"
    attribute_type = "S"
  }]
  billing_mode = "PAY_PER_REQUEST"
  on_demand_throughput = {
    max_read_request_units  = 10
    max_write_request_units = 10
  }
  deletion_protection_enabled = false
}

Debug Output

2024-06-30T12:24:59.989-0700 [WARN]  Provider "registry.terraform.io/hashicorp/awscc" produced an unexpected new value for awscc_dynamodb_table.table_name during refresh.
      - .key_schema: was cty.StringVal("[{\"AttributeName\":\"id\",\"KeyType\":\"HASH\"}]"), but now null
. . .
2024-06-30T12:25:00.010-0700 [DEBUG] provider.terraform-provider-awscc_v1.4.0_x5: Detected value change between proposed new state and prior state: tf_attribute_path=time_to_live_specification tf_provider_addr=registry.terraform.io/hashicorp/awscc tf_req_id=48229811-0d75-10f6-f9c7-cc9dcf15eb02 tf_rpc=PlanResourceChange @caller=github.com/hashicorp/[email protected]/internal/fwserver/server_planresourcechange.go:208 @module=sdk.framework tf_resource_type=awscc_dynamodb_table timestamp=2024-06-30T12:25:00.010-0700
2024-06-30T12:25:00.011-0700 [DEBUG] provider.terraform-provider-awscc_v1.4.0_x5: Detected value change between proposed new state and prior state: tf_rpc=PlanResourceChange @caller=github.com/hashicorp/[email protected]/internal/fwserver/server_planresourcechange.go:208 tf_attribute_path=key_schema tf_resource_type=awscc_dynamodb_table @module=sdk.framework tf_provider_addr=registry.terraform.io/hashicorp/awscc tf_req_id=48229811-0d75-10f6-f9c7-cc9dcf15eb02 timestamp=2024-06-30T12:25:00.010-0700
2024-06-30T12:25:00.011-0700 [DEBUG] provider.terraform-provider-awscc_v1.4.0_x5: Detected value change between proposed new state and prior state: tf_req_id=48229811-0d75-10f6-f9c7-cc9dcf15eb02 tf_rpc=PlanResourceChange @caller=github.com/hashicorp/[email protected]/internal/fwserver/server_planresourcechange.go:208 tf_attribute_path=sse_specification tf_provider_addr=registry.terraform.io/hashicorp/awscc tf_resource_type=awscc_dynamodb_table @module=sdk.framework timestamp=2024-06-30T12:25:00.010-0700
2024-06-30T12:25:00.011-0700 [DEBUG] provider.terraform-provider-awscc_v1.4.0_x5: Detected value change between proposed new state and prior state: @caller=github.com/hashicorp/[email protected]/internal/fwserver/server_planresourcechange.go:208 @module=sdk.framework tf_resource_type=awscc_dynamodb_table tf_rpc=PlanResourceChange tf_attribute_path=contributor_insights_specification tf_provider_addr=registry.terraform.io/hashicorp/awscc tf_req_id=48229811-0d75-10f6-f9c7-cc9dcf15eb02 timestamp=2024-06-30T12:25:00.

Expected Behavior

Subsequent terraform plan after the first terraform apply should not register any drift

Actual Behavior

Subsequent terraform plan after the first terraform apply detected a drift

awscc_dynamodb_table.table_name: Refreshing state... [id=table-name]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # awscc_dynamodb_table.table_name will be updated in-place
  ~ resource "awscc_dynamodb_table" "table_name" {
      + global_secondary_indexes             = (known after apply)
        id                                   = "table-name"
      + import_source_specification          = (known after apply)
      + key_schema                           = jsonencode(
            [
              + {
                  + AttributeName = "id"
                  + KeyType       = "HASH"
                },
            ]
        )
      + kinesis_stream_specification         = (known after apply)
      + local_secondary_indexes              = (known after apply)
      + provisioned_throughput               = (known after apply)
      + resource_policy                      = (known after apply)
      + stream_arn                           = (known after apply)
      + stream_specification                 = (known after apply)
      + table_class                          = (known after apply)
      + tags                                 = (known after apply)
        # (10 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Steps to Reproduce

1. terraform apply
2. terraform plan

Important Factoids

References

• Part of the problem might be related to #1216