[Bug]: When expanding the plan for aws_ecs_service.qa-ecs-service [...] provider aws produced an invalid new value for .triggers["redeployment"]: was cty.StringVal("2022-11-28T16:50:44Z"), but now │ cty.StringVal("2022-11-28T18:08:03Z").

[domvo]

Terraform Core Version

v1.3.5

AWS Provider Version

v4.41.0

Affected Resource(s)

• aws_ecs_service

Expected Behavior

Running apply multiple times with an aws_ecs_service that has force_new_deployment set to true should run a new deployment of the given ecs Service.

Actual Behavior

It shows an error and doesn't run apply (or when it applies, it doesn't do anything, because it says "No Changes").

Relevant Error/Panic Output Snippet

| Error: Provider produced inconsistent final plan
│
│ When expanding the plan for aws_ecs_service.qa-ecs-service 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("2022-11-28T16:50:44Z"), but now
│ cty.StringVal("2022-11-28T18:08:03Z").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Terraform Configuration Files

resource "aws_ecs_service" "qa-ecs-service" {
  name            = "qa-${var.pr_id}-ecs-service"
  cluster         = var.cluster_arn
  task_definition = aws_ecs_task_definition.qa-task-definition.arn
  desired_count   = 1
  launch_type     = "FARGATE"
  network_configuration {
    subnets       = var.subnets
    security_groups = var.security_groups
    assign_public_ip = true 
  }
  load_balancer {
    target_group_arn  = aws_lb_target_group.qa-target-group.arn
    container_name    = "qa-${var.pr_id}-container"
    container_port    = "8080"
  }
  force_new_deployment = true

  triggers = {
    redeployment = timestamp()
  }
}

Steps to Reproduce

• terraform apply
• terraform apply

Debug Output

No response

Panic Output

No response

Important Factoids

No response

References

No response

Would you like to implement a fix?

No response

[github-actions]

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.

[rnithinpaladin]

same issue

[simon-turnbull-healx]

Same issue as well using Terraform v1.3.6 with hashicorp/aws v4.50.0

When expanding the plan for module.xyz.aws_ecs_service.service 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-01-19T09:58:45Z"), but now cty.StringVal("2023-01-19T12:58:17Z").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker

[mshanks1983]

Any updates on this yet? It's proving to be a pretty big blocker for some of my deployment efforts.

[mshanks1983]

Would it reduce the likelihood of hitting this bug if I used something like date() instead of time()? Something that doesn't change with the time as quickly?

[nathanhruby]

Did you try using true instead of timestamp()?

[scheleaap]

This is likely a duplicate of #19583.

[lordz-ei]

Did you try using true instead of timestamp()?

I assume you mean
triggers = { redeployment = true }

[lordz-ei]

@nathanhruby, setting
triggers = { redeployment = true }
does not have any efect in my case

[Surgo]

It's works fine for me.

  triggers = {
    redeployment = plantimestamp()
  }

[LozanoMatheus]

@Surgo did you also set the force_new_deployment = true or just triggers.redeployment?