terraform-provider-aws: data.aws_ecs_task_definition: Failed getting task definition

Terraform Version

0.9.11.

aws_ecs_task_definition

Terraform Configuration Files

data "aws_ecs_task_definition" "my-service" {
  task_definition = "${aws_ecs_task_definition.my-service.family}"
}

resource "aws_ecs_task_definition" "my-service" {
  family                = "${var.environment_name}-${var.service_name}-${var.instance_name}"
  network_mode          = "bridge"
  container_definitions = "${data.template_file.my-service.rendered}"
}

resource "aws_ecs_service" "my-service" {
 ...
  #Track the latest ACTIVE revision
  task_definition = "${aws_ecs_task_definition.my-services.family}:${max("${aws_ecs_task_definition.my-service.revision}", "${data.aws_ecs_task_definition.my-service.revision}")}"
...
}

Expected Behavior

if resource not exists create new aws_ecs_task_definition else use latest aws_ecs_task_definition version

this code vork fine in Terraform v0.9.2

Actual Behavior

: Failed getting task definition ClientException: Unable to describe task definition. status code: 400, request id: “my-service”

Steps to Reproduce

terraform apply

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 32
Comments: 28 (9 by maintainers)

Commits related to this issue

data.aws_ecs_task_definition: Failed getting task definition (#6) Fix in PR. See: https://github.com/terraform-providers/terraform-provider-aws/issues/1274#issuecomment-331332157 — committed to duduribeiro/terraform_ecs_fargate_example by jumbojett 5 years ago
Provide a working example for ecs-task-definition This is working around the issue of not having a task definition when the resources are initially rolled out. Background: The documetation example ... — committed to skorfmann/terraform-provider-aws by deleted user 5 years ago

Most upvoted comments

I was able to get around this issue by adding a “depends_on” to the data source:

resource "aws_ecs_task_definition" "task" {
...
}
data "aws_ecs_task_definition" "task" {
  depends_on = [ "aws_ecs_task_definition.task" ]
  ...
}

Hope it helps.

+133

parruda on Sep 22, 2017

This issue isn’t very clear to me. Seems like some folks claim that we should NOT be using a depends_on in the datasource for the task definition but upon the first run it always fails because the resource doesnt exist.

ldiaz2-chwy on Jun 25, 2019

Ya I probably should of tried the fix before replying, it works but it causes continuous change detection to occur. Which is not the expected/desired result

kazeshini178 on Dec 12, 2017

Actually, what I said is a lie, looks like there is a problem when you have an invalid JSON for container definitions and mine is not using the heredoc syntax but a json file with a template and it should be an array of containers and i have only one main object. Here where I found out about it https://github.com/terraform-providers/terraform-provider-aws/issues/2026

jaysonsantos on Dec 5, 2018

FYI for everybody else stumbling over the issue: @skorfmann illustrated in this MR https://github.com/terraform-providers/terraform-provider-aws/pull/10247 a better workaround using aws_ecs_task_definition.self.revision and explains why the discussed depends_on approach is not what you want!

This is working around the issue of not having a task definition when the resources are initially rolled out. The documetation example of directly referecing “task_family” doesn’t work and exits with an error when initially applying it. See also this issue #1274

The reason is, that data sources don’t handle missing data gracefully. Unfortunately, that’s not gonna be addressed, as stated here: hashicorp/terraform#16380 (comment). One of the suggested workarounds is, to add an explict depends_on. However, this causes a potential change in the terraform plan output, even though it’s not actually going to change. Furthermore, it’s discourage by the Terraform documentation itself.

This thread mentions a few other workarounds, but none of them seem to be suitable hashicorp/terraform#16380

aws_ecs_task_definition.self.revision can only be referenced, once the resource is created (in contrast to family, which is already present in code). Apparently, this allows Terraform to correctly resolve the dependencies and makes the data source behave as expected.

bentolor on Oct 8, 2020

Diving into debugging… I’ve noticed that func dataSourceAwsEcsTaskDefinitionRead does not get called in a vanilla project, but does in an existing one. This appears to be a terraform pattern. I was able to reproduce this by creating a simple resource first (a security group) then trying to perform a lookup. The plan failed when a resource was already present in a statefile (the security group in this case). I verified my hypothesis by also creating a different data source which looked up a non-existent security group. The plan for this also failed.

nathanielks on Aug 28, 2017