Terraform always re-plans changes when using rds-logs module

[qnm]

Versions

All I've tried. Currently 1.1.0. Using Terraform 1.5.4.

Steps to reproduce

1. Configure the honeycombio/integrations/aws//modules/rds-logs as a single module e.g.

module "honeycomb-aws-rds-social-logs-integration" {
  source = "honeycombio/integrations/aws//modules/rds-logs"
  version = "1.1.0"

  name                   = "rds-social-production"
  db_engine              = "postgresql"
  db_name                = "production-postgres-1234"
  db_log_types           = ["postgresql"]
  honeycomb_api_key      = var.honeycomb // Honeycomb API key.
  honeycomb_dataset_name = "rds"

  s3_failure_bucket_arn = module.firehose_failure_bucket.s3_bucket_arn

  tags = {
    "App"         = aws_db_instance.social.tags.App
    "Environment" = aws_db_instance.social.tags.Rack
  }
}

2. Plan and Apply
3. Plan again, see that changes still are required, parameters are swapped:

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:

  # module.honeycomb-aws-rds-social-logs-integration.module.cloudwatch_logs.module.kfh.aws_kinesis_firehose_delivery_stream.http_stream will be updated in-place
  ~ resource "aws_kinesis_firehose_delivery_stream" "http_stream" {
        id             = "arn:aws:firehose:ap-southeast-2:xxx:deliverystream/rds-social-production"
        name           = "rds-social-production"
        tags           = {}
        # (5 unchanged attributes hidden)

      ~ http_endpoint_configuration {
            name               = "honeycomb"
            # (7 unchanged attributes hidden)

          ~ processing_configuration {
                # (1 unchanged attribute hidden)

              ~ processors {
                    # (1 unchanged attribute hidden)

                  ~ parameters {
                      ~ parameter_name  = "LambdaArn" -> "BufferIntervalInSeconds"
                      ~ parameter_value = "arn:aws:lambda:ap-southeast-2:xxx:function:rds-social-production-honeycomb-rds-postgresql-log-parser:$LATEST" -> "61"
                    }
                  ~ parameters {
                      ~ parameter_name  = "BufferIntervalInSeconds" -> "LambdaArn"
                      ~ parameter_value = "61" -> "arn:aws:lambda:ap-southeast-2:xxx:function:rds-social-production-honeycomb-rds-postgresql-log-parser:$LATEST"
                    }

                    # (1 unchanged block hidden)
                }
            }

            # (3 unchanged blocks hidden)
        }

        # (1 unchanged block hidden)
    }

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

Additional context

This doesn't actually cause a problem, it's more that it's difficult to determine legitimate changes.

I've tried a few terraform versions and still see this issue.

[jharley]

Thanks for reporting this!

Ultimately, this is a manifestation of hashicorp/terraform-provider-aws#9827 and there isn't a lot we can do (we've tried in #16 previously to improve this behaviour).

Short of making this parameters unconfigurable (which, even then may trigger this bug given that ordering could change on the API side) I'm not sure how to improve this.

Open to suggestions, however!

[qnm]

Thanks for reporting this!

Ultimately, this is a manifestation of hashicorp/terraform-provider-aws#9827 and there isn't a lot we can do (we've tried in #16 previously to improve this behaviour).

Short of making this parameters unconfigurable (which, even then may trigger this bug given that ordering could change on the API side) I'm not sure how to improve this.

Open to suggestions, however!

Thanks for the acknowledgement.

The latest comments in the linked issue suggest param order is important. If I get a chance I will see if the technique mentioned has any effect.

[jharley]

@qnm v1.2.1 was just released and includes an attempt at fixing this annoying behaviour.