Erroneous "Resource ... does not have attribute" error; goes away on second apply

[jbrwon2006]

Terraform Version

v0.10.2

Terraform Configuration Files

variable "a" {}
variable "b" {}
resource "template_file" "a" {
  count    = "${var.a}"
  template = "a${count.index}"
}
resource "template_file" "b" {
  count    = "${var.b}"
  template = "b${count.index}"
}
resource "template_file" "out" {
  template = "${join(",", concat(template_file.a.*.rendered, template_file.b.*.rendered))}"
}
output "data" {
  value = "${template_file.out.rendered}"
}

Steps to Reproduce

# terraform init && terraform apply -var a=2 -var b=2
 Shows expected: a0,a1,b0,b1

# terraform plan -var a=2 -var b=0
 Shows expected: a0,a1

# terraform apply -var a=2 -var b=0
 Fails
* template_file.out: Resource 'template_file.b' does not have attribute 'rendered' for variable 'template_file.b.*.rendered'

# terraform apply -var a=2 -var b=0
 Works as expected: a0,a1

I tried to use a conditional, but that does not work since both branches need to be evaluated. I am assuming this is a bug since re-run works.

[apparentlymart]

Hi @jbrwon2006! Sorry this isn't working properly.

I think the problem here is not actually related to the splat expression; what you did here should've worked.

This looks similar to hashicorp/terraform-provider-template#2, which is unfortunately something we've never been able to get to the bottom of despite it being encountered a few times now. 😖

I'll see if I can reproduce with your config here. Thanks for this self-contained example config!

[apparentlymart]

I was indeed able to reproduce this. Thanks!

I noticed while running it that this is using the deprecated resource form of template_file rather than the new data source, and indeed it seems to work as expected when the data source is in use.

However, it's still a bug, and one that quite possibly affects other resources too. Hopefully with this great repro case we can get to the bottom of this, so thanks again!

[phinze]

Hey folks! @mmcquillan and I just reproduced this error in a very similar scenario with a blue/green set of aws_instance resources assigned to an aws_elb. That suggests that this is indeed an expression of a general issue where a splat reference points to a collection of resources that are going from count > 0 to count = 0.

[robrankin]

I think I'm running into this issue now, specifically when a resource goes from count > 0 to count = 0, as mentioned by @phinze above.

Reproduction code.

terraform {
  required_version = "= 0.11.3"
}

provider "azurerm" {
  version         = "= 1.2.0"
}

variable "resourceCount" { default = 1 }
variable "name" {  default = "test001-rg" }
variable "location" { default = "northeurope" }

resource "azurerm_resource_group" "resourceGroup" {
  count    = "${var.resourceCount}"
  name     = "${var.name}"
  location = "${var.location}"
}

output "name" {
  value = "${element(concat(azurerm_resource_group.resourceGroup.*.name, list("")), 0)}"
}

output "id" {
  value = "${element(concat(azurerm_resource_group.resourceGroup.*.id, list("")), 0)}"
}

output "location" {
  value = "${element(concat(azurerm_resource_group.resourceGroup.*.location, list("")), 0)}"
}

Reproduction Steps
Step 1:

# terraform apply -var resourceCount=1
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:

id = /subscriptions/xyz-abc-etc/resourceGroups/test001-rg
location = northeurope
name = test001-rg

Step 2:

# terraform apply -var resourceCount=0

azurerm_resource_group.resourceGroup: Destruction complete after 45s

Error: Error applying plan:

3 error(s) occurred:

* output.name: Resource 'azurerm_resource_group.resourceGroup' does not have attribute 'name' for variable 'azurerm_resource_group.resourceGroup.*.name'
* output.id: Resource 'azurerm_resource_group.resourceGroup' does not have attribute 'id' for variable 'azurerm_resource_group.resourceGroup.*.id'
* output.location: Resource 'azurerm_resource_group.resourceGroup' does not have attribute 'location' for variable 'azurerm_resource_group.resourceGroup.*.location'

Step 3:

# terraform apply -var resourceCount=0

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

id =
location =
name =

[robrankin]

@jbardin @apparentlymart

I've tried it with 0.11.4, which has #17241 merged in, and I'm still seeing the errors. Not sure if it should be fixed by #17241 or not?

[jbardin]

Hi @robrankin,

17241 solved the issue on a full destroy, but it's going to take a little more work to fix when resources are being replaced. Issue #17425 describes the situation a little more precisely.

[robrankin]

@jbardin Thanks for the response, appreciate that. Will watch the other issue keenly.

[srghma]

v 0.11.7

I have an expression

resource "aws_spot_instance_request" "stage" {
   ...
}

resource "local_file" "stage" {
  content  = "{ ip = \"${aws_spot_instance_request.stage.public_ip}\"; }"
  filename = "${path.module}/machines/stage/autogenerated.nix"
}

I make

1. terraform apply - creates instance, but throws error

Error: Error applying plan:

1 error(s) occurred:

* local_file.stage: Resource 'aws_spot_instance_request.stage' does not have attribute 'public_ip' for variable 'aws_spot_instance_request.stage.public_ip'

2. terraform apply second time - error goes away, local_file is written

P.S.

adding depends_on

resource "local_file" "stage" {
  content  = "{ ip = \"${aws_spot_instance_request.stage.public_ip}\"; }"
  filename = "${path.module}/machines/stage/autogenerated.nix"
  depends_on = ["aws_spot_instance_request.stage"]
}

doesn't help

[teamterraform]

Hi folks!
The original issue is fixed in terraform 0.12, so I am going to close this.
Anyone experiencing a similar-looking problem should open a new issue and fill out the issue template. Thank you!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.