[Bug]: Triggers on ECS Service don't result in changes

[creeder-uturn]

Terraform Core Version

1.2.9, 1.3.7

AWS Provider Version

4.40.0, 4.53.0

Affected Resource(s)

aws_ecs_service

Expected Behavior

When using the triggers = {} parameter (introduced here: https://github.com/hashicorp/terraform-provider-aws/pull/25840), changes to the triggers should result in a change in the terraform resource.

Actual Behavior

Changing the triggers = {}, including complete removal, results in no difference in plan

Relevant Error/Panic Output Snippet

No response

Terraform Configuration Files

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.40"
    }
  }
}

resource "aws_ecs_cluster" "main" {
  name = "bug-demo"
}

resource "aws_ecs_service" "main" {
  name            = "bug-demo"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.main.arn

  force_new_deployment = true

  # BUG HERE: Changes to triggers seems to not reflect with a diff in plan/apply
  triggers = {
    redeployment = timestamp()
  }
}

resource "aws_ecs_task_definition" "main" {
  family = "bug-demo"

  container_definitions = jsonencode([{
    name      = "sleep"
    image     = "busybox"
    cpu       = 10
    memory    = 10
    command   = ["sleep", "360"]
    essential = true
  }])
}

Steps to Reproduce

Apply the above terraform. Apply again. timestamp() should result in triggers changing. It does not.

Debug Output

No response

Panic Output

No response

Important Factoids

No response

References

This seems to be when this feature was introduced, and as far as I can tell it has never worked: https://github.com/hashicorp/terraform-provider-aws/pull/25840

Would you like to implement a fix?

No

[github-actions[bot]]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• 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.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[creeder-uturn]

Additional finding around this feature: if you flip force_new_deployment to false in the above test, apply, then flip it back to true, you get:

│ Error: Provider produced inconsistent final plan
│
│ When expanding the plan for aws_ecs_service.main to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new
│ value for .triggers["redeployment"]: was cty.StringVal("2023-02-03T17:53:36Z"), but now cty.StringVal("2023-02-03T18:08:09Z").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

[gtskaushik]

I'm facing the same issue. A change in triggers is not detected during plan or apply. Also when trying apply multiple times, I ended up in this error

When expanding the plan for aws_ecs_service.main to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new │ value for .triggers["redeployment"]: was cty.StringVal("2023-02-03T17:53:36Z"), but now cty.StringVal("2023-02-03T18:08:09Z").

[gtskaushik]

This looks like a duplicate of https://github.com/hashicorp/terraform-provider-aws/issues/28070

[gtskaushik]

I found a workaround for this.

1. Create a new variable

   variable "timestamp_id" {
   type = string
   default = ""
   }

2. Pass the value during plan or apply -var="timestamp_id=$(date)
3. Change in aws_ecs_service

   force_new_deployment = true
   triggers = {
   redeployment = var.timestamp_id
   }

[jonathan-heartland]

I am encountering this same problem.

Error: Provider produced inconsistent final plan │ │ When expanding the plan for │ module.ecs.aws_ecs_service.instance["main"] to include new values │ learned so far during apply, provider "registry.terraform.io/hashicorp/aws" │ produced an invalid new value for .triggers["redeployment"]: was │ cty.StringVal("2023-05-02T16:13:05Z"), but now │ cty.StringVal("2023-05-02T17:01:34Z"). │ │ This is a bug in the provider, which should be reported in the provider's │ own issue tracker.

My Terraform Apply's are all pipelined, so adding a workaround is not ideal.

[lordz-ei]

I am encountering this same problem.

Error: Provider produced inconsistent final plan │ │ When expanding the plan for │ module.ecs.aws_ecs_service.instance["main"] to include new values │ learned so far during apply, provider "registry.terraform.io/hashicorp/aws" │ produced an invalid new value for .triggers["redeployment"]: was │ cty.StringVal("2023-05-02T16:13:05Z"), but now │ cty.StringVal("2023-05-02T17:01:34Z"). │ │ This is a bug in the provider, which should be reported in the provider's │ own issue tracker.

My Terraform Apply's are all pipelined, so adding a workaround is not ideal.

Same issue here

[Surgo]

It's works fine for me.

  triggers = {
    redeployment = plantimestamp()
  }

[aszniak]

Right, it works for plantimestamp(), but I wanted to make it redeploy on config change. Something along the lines of:

 triggers = {
    redeployment = filesha256("${path.module}/files/service-config.yml")
 }

Does not seem to work