The "count" value depends on resource attributes that cannot be determined until apply, but resource attributes are already applied

[dimisjim]

Terraform Version

0.13.1

Terraform Configuration Files

#################
# at root level #
#################

module "profileapi" {
  source                 = "./modules/s3_bucket"
  bucket_name            = "1plusx-profileapi"
  enable_versioning      = true
  retention_days         = 7
  destination_bucket_arn = module.profileapi-dub.bucket_arn

  providers = {
    aws = aws.frankfurt
  }
}

module "profileapi-dub" {
  source            = "./modules/s3_bucket"
  bucket_name       = "1plusx-profileapi-dub"
  enable_versioning = true
  retention_days    = 7

  providers = {
    aws = aws.dublin
  }
}

output "test" {
  value = module.profileapi-dub.bucket_arn
}

###########################
# inside s3_bucket module #
###########################
locals {
  enable_replication = signum(length(var.destination_bucket_arn)) == 1 ? true : false
  replication_cnt    = signum(length(var.destination_bucket_arn))
}

resource "aws_s3_bucket" "logged_retention_crrd_bucket" {
  count         = var.enable_logging && var.enable_expiration && local.enable_replication && false == local.enable_encryption ? 1 : 0
...
}

resource "aws_s3_bucket" "logged_retention_bucket" {
  count         = var.enable_logging && var.enable_expiration && var.encryption_algorithm == "" && false == local.enable_replication ? 1 : 0
...
}

resource "aws_s3_bucket" "retention_bucket" {
  count         = false == var.enable_logging && var.enable_expiration && var.encryption_algorithm == "" && false == local.enable_replication ? 1 : 0
...
}

resource "aws_s3_bucket" "logged_bucket" {
  count         = var.enable_logging && false == var.enable_expiration && var.encryption_algorithm == "" && false == local.enable_replication ? 1 : 0
...
}

Debug Output

Trace outputs were too large for gist, so used gdrive instead

• When output is not explicitly defined at root (and state has been refreshed to make sure it is removed) :
  https://drive.google.com/file/d/16w0cj2NWDVLSWnYJdNqiLu6aO-hY84lK/view?usp=sharing

Snippet of the errors:

Error: Invalid count argument

  on modules/s3_bucket/main.tf line 434, in resource "aws_s3_bucket" "logged_retention_crrd_bucket":
 434:   count         = var.enable_logging && var.enable_expiration && local.enable_replication && false == local.enable_encryption ? 1 : 0

The "count" value depends on resource attributes that cannot be determined
until apply, so Terraform cannot predict how many instances will be created.
To work around this, use the -target argument to first apply only the
resources that the count depends on.

• When having defined the output at root level, and by having applied targeting specifically the module containing the required output, there is no error:
  https://drive.google.com/file/d/1awuoO8c_bZJObV1vlU0d0k-Uh7CrUZhH/view?usp=sharing

Expected Behavior

As it was in 0.12, the module output should be computed and provided to the root level where it is referenced as one of another's module's inputs, without having to explicitly define an output value with it. Commands like state show correctly output the state that the other module presumes that has never been applied.

Actual Behavior

tf 0.13 thinks that module has never been applied, and therefore its output is not available to another module which uses it as an input.

Steps to Reproduce

1. Define the outputs and apply to make them available
2. Run tf plan, which works fine
3. Remove the outputs, and apply again in order to remove them from the state.
4. Plan again, now you get "Error: Invalid count argument"

Additional Context

Nothing special in particular.

[shajithravi]

Im facing the same issue with 0.12.29
The resources are already deployed, but I get this error all of a sudden for past few days.

Edit: Im facing this issue after upgrading from 0.12.25 to 0.12.29

[woz5999]

same on 0.13.2

[dawidmalina]

I am having the same issue and I thought that this will be solved by terraform 0.13 and depends_on on module level. But it's not working :(

module "a" {
  source = "./modules/a"
}

module "b" {
  source     = "./modules/b"
  uuid       = module.a.uuid
  depends_on = [module.a]
}

[acdha]

I ran into another variation: if a module has an output which happens to be empty, it will always hit this error even though it should be perfectly legal to have count=0 for an a optional feature. In my case, it was easy to resolve by changing count = length(module.public_web.instance_ids) to for_each = toset(module.public_web.instance_ids) but it seems like this could be improved.

[alisdair]

@dimisjim Thanks for reporting this!

Unfortunately I am having trouble understanding your report and following the reproduction steps. The configuration you provided seems to be missing some variable values, and is quite complex. So that we can reproduce and fix this issue, can you help me create a smaller reproduction configuration?

Here is what I've tried, which is based on my understanding of your report:

main.tf:

module "a" {
  source    = "./child"
  name      = "a"
  input_ids = ["test"]
}

module "b" {
  source    = "./child"
  name      = "b"
  input_ids = module.a.ids
}

child/main.tf:

variable "name" {
  type = string
}

variable "input_ids" {
  type    = list(string)
  default = []
}

locals {
  enabled = length(var.input_ids) > 0
}

resource "null_resource" "x" {
  count = local.enabled ? 1 : 0
}

output "ids" {
  value = null_resource.x.*.id
}

Unfortunately this successfully plans, even from an empty state. As you can see, the module outputs are not copied through as outputs from the root module, which I think is what you identified as the problem you saw.

Can you modify this configuration to make it similar to your own and reproduce the bug? Failing that, can you simplify your original configuration, ideally using null_resource, and provide an isolation reproduction case?

Thanks in advance for your help!

[dimisjim]

@alisdair Your example indeed works. I also have other modules that take up values from other modules, so the issue that I am having is particular to one type of module co-dependence. Not sure how I could reproduce it extending your example.

[zachwhaley]

I may have reproduced this bug. Check out https://github.com/zachwhaley/tfbug-26078

$ terraform apply
var.create_asc
  Enter a value: false


An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # module.org.null_resource.this will be created
  + resource "null_resource" "this" {
      + id = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

module.org.null_resource.this: Creating...
module.org.null_resource.this: Creation complete after 0s [id=2709081041753520259]

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

$ terraform apply
var.create_asc
  Enter a value: false

module.org.null_resource.this: Refreshing state... [id=2709081041753520259]

Error: Invalid count argument

  on asc/main.tf line 15, in resource "null_resource" "this":
  15:   count = var.create ? 1 : 0

The "count" value depends on resource attributes that cannot be determined
until apply, so Terraform cannot predict how many instances will be created.
To work around this, use the -target argument to first apply only the
resources that the count depends on.

[alisdair]

Thanks, @zachwhaley! 👍 I can reproduce the issue on 0.13.2 and 0.13.3.

The good news is that it appears to be fixed with a build from the latest main branch, due to #26270. I'm going to leave this issue open but expect this issue to be fixed with the release of 0.14.0.