versionConsistency drift in container-definition module

[caiohasouza]

Description

When using the container-definition submodule, the variable version_consistency is always rendered into the container definition JSON, even when not wanted.
This causes drift in environments where ECS task definitions are also updated by CodePipeline (ECS Deploy action), because CodePipeline does not preserve the versionConsistency field when it registers a new revision.

As a result, terraform plan always shows a difference and forces replacement of the task definition.

If I clone the module locally and change the variable to nullable = true with default = null, then pass null, the module omits the field and the drift disappears.

I believe the module should support omitting this attribute when not explicitly set.

• ✋ I have searched the open/closed issues and my issue is not listed.

⚠️ Note

• Cleared .terraform and reinitialized.
• The issue persists with the latest module and provider.

Versions

• Module version: terraform-aws-modules/ecs/aws v6.6.0
• Terraform version: v1.12.x
• Provider version(s): hashicorp/aws v6.14.1

Reproduction Code [Required]

module "container_definition" {
  source  = "terraform-aws-modules/ecs/aws//modules/container-definition"

  name  = "app"
  image = "nginx:latest"

  # Do not set version_consistency
}

Steps to reproduce:

1. terraform init && terraform apply → task definition created with "versionConsistency": "disabled".
2. Run a deploy through CodePipeline with imagedefinitions.json → a new revision is created without versionConsistency.
3. terraform plan now shows a diff on container_definitions and forces replacement.

Expected behavior

• If version_consistency is not provided, the module should omit the field entirely from the container definition JSON.
• This avoids drift when other tools (like CodePipeline ECS Deploy action) do not include the field.

Actual behavior

• The module always renders "versionConsistency": "disabled", even when unset.
• This causes perpetual drift whenever CodePipeline creates a new task definition revision.

Terminal Output Screenshot(s)

  # module.ecs_service.aws_ecs_task_definition.this[0] must be replaced
+/- resource "aws_ecs_task_definition" "this" {
      ~ arn                      = "arn:aws:ecs:us-east-1:496610455293:task-definition/test-ecs:37" -> (known after apply)
      ~ arn_without_revision     = "arn:aws:ecs:us-east-1:496610455293:task-definition/test-ecs" -> (known after apply)
      ~ container_definitions    = jsonencode(
          ~ [
              ~ {
                    name                   = "app"
                  + versionConsistency     = "disabled"
                    # (19 unchanged attributes hidden)
                },
            ] # forces replacement
        )
      ~ enable_fault_injection   = false -> (known after apply)
      ~ id                       = "test-ecs" -> (known after apply)
      ~ revision                 = 37 -> (known after apply)
        tags                     = {
            "Name" = "test-ecs"
        }
        # (13 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Additional context

• By patching the module locally to allow nullable = true and default = null, and omitting the value, the drift disappears.
• Suggestion: adjust the variable definition and JSON merge logic so that versionConsistency is omitted when null, instead of always rendered.

[bryantbiggs]

We have set a default so you will have to provide an alternate value if you do not agree with the default we've specified. Null is not an option in this case

[caiohasouza]

I understand the default choice, but the problem is that CodePipeline’s ECS Deploy action does not preserve the versionConsistency field when registering a new revision.
This results in perpetual drift between Terraform (which always renders it) and the task definitions created by CodePipeline (which omit it).

Is this drift expected? Or would it make sense to support an opt-out / omission mode for users that rely on CodePipeline?
Right now the only workaround is to fork the module or use ignore_changes, both of which feel suboptimal.

[bryantbiggs]

I don't know what CodePipeline does or how its configured, but I would configure it to match nearly all of what you are specifying in your Terraform and then expect that its only updating the image tag of the version to deploy