Config values are evaluated when passed from heroku_config to heroku_app_config_association

[c-carpenter]

Versions

Terraform v0.11.14
+ provider.heroku v2.2.2

Affected Resource(s)

• heroku_config
• heroku_app_config_association

Terraform Configuration Files

terraform {
  required_version = "0.11.14"

  backend "s3" {
    bucket               = "livemessage-terraform-state"
    workspace_key_prefix = "state-one"
    key                  = "terraform.tfstate"
    region               = "us-east-1"
    encrypt              = true

    skip_credentials_validation = true
  }
}

provider "heroku" {
  version = "~> 2.2.2"
}

variable "skip" {
  default = false
}

resource "heroku_app" "app" {
  count  = "${var.skip ? 0 : 1}"
  name   = "state-one"
  region = "us"
}

resource "heroku_config" "pod" {
  vars = {
    first = "true"
    second = "b"
  }
  sensitive_vars = {
    alpha = "1"
    beta = "2"
    gamma = "3"
    delta = "4"
  }
}

resource "heroku_app_config_association" "pod" {
  app_id = "${heroku_app.app.id}"
  vars = "${heroku_config.pod.vars}"
  sensitive_vars = "${heroku_config.pod.sensitive_vars}"
}

Debug Output

https://gist.github.com/c-carpenter/e0e5de2d14782ef230a1b8fc6ffe69a9

Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

heroku_config.pod: Refreshing state... (ID: config-1581713468)
heroku_app.app: Refreshing state... (ID: state-one)
heroku_app_config_association.pod: Refreshing state... (ID: config:state-one)

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ heroku_app_config_association.pod
      vars.first: "a" => "1"

  ~ heroku_config.pod
      vars.first: "a" => "true"


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

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Expected Behavior

What should have happened?
Config values should be preserved.

Actual Behavior

What actually happened?
When config values are passed from heroku_config to heroku_app_config_association, they are evaluated. This results in true/false values becoming 1/0.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. Setup a TF that has heroku_config, and is consumed by heroku_app_config_association.
2. terraform plan - It shows up in the plan.

[c-carpenter]

If you pass the values directly into heroku_app_config_association, then it doesn't convert from boolean to int.

resource "heroku_app_config_association" "pod" {
  app_id = "${heroku_app.app.id}"
  vars = {
    first = "true"
    second = "b"
  }
  sensitive_vars = {
    alpha = "1"
    beta = "2"
    gamma = "3"
    delta = "4"
  }
}

[mars]

While I agree that this behavior seems wrong, it's not the whole story.

Heroku config vars are all strings. There are no other types.

So, it seems that the provider is converting non-string values to an unexpected string value. This would be an error in the Terraform SDK, which handles reading attribute values from HCL.

Workaround is to only ever set string values for config vars.

Such an old issue, maybe this has been fixed since then.

A fix at this time would require:

• reproduce with current version of this provider
• determine root cause
• probably, address through issue on Terraform SDK.