Plan incorrectly reports that it will delete existing resource data

[bernerdschaefer]

Terraform Version

% terraform -v
Terraform v0.10.2

Terraform Configuration Files

Initial configuration:

resource "heroku_app" "example" {
  name   = "fast-crag-77469"
  region = "us"

  config_vars = {
    FOO = "bar"
  }
}

Configuration after apply:

resource "heroku_app" "example" {
  name   = "fast-crag-77469"
  region = "us"

  config_vars = {
    FOO    = "bar"
    SECRET = "${random_id.secret.hex}"
  }
}

resource "random_id" "secret" {
  byte_length = 16
}

Debug Output

https://gist.github.com/bernerdschaefer/6cd4b1937ff1d51b1fbe0042fcfa8936

Expected Behavior

I expect the plan to show that a new config var SECRET will be added to the
app, whose value comes from the new random_id.secret resource. For example:

  ~ heroku_app.example
      config_vars.0.%:      "1" => "2"
      config_vars.0.SECRET: "" => "<computed>"

  + random_id.secret
      b64:         "<computed>"
      b64_std:     "<computed>"
      b64_url:     "<computed>"
      byte_length: "16"
      dec:         "<computed>"
      hex:         "<computed>"


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

Actual Behavior

$  terraform plan

  ~ heroku_app.example
      config_vars.0.%:   "" => "<computed>"
      config_vars.0.FOO: "bar" => ""

  + random_id.secret
      b64:         "<computed>"
      b64_std:     "<computed>"
      b64_url:     "<computed>"
      byte_length: "16"
      dec:         "<computed>"
      hex:         "<computed>"


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

The plan in fact shows that it will delete the existing FOO configuration
variable, and does not mention the new SECRET variable at all.

This causes us some anxiety when applying such a change in production -- we
basically have to trust that apply will do the right thing even when the plan
says it will remove critical configuration information from the app.

It also took a lot of trial and error to trace this back to the dependency on a
new resource; before it seemed like terraform would "randomly" report it would
delete all of our configurations.

Steps to Reproduce

1. terraform init
2. terraform apply
3. Update config_vars to depend on a new resource
4. terraform plan

Important Factoids

This is not limited to random_id, but any new resource which has not yet been
applied.

Note that apply in fact does the right thing -- it's only the generated plan
that's incorrect / confusing.

The heroku provider seems to be doing pretty standard stuff here, so I don't
think this is specific to the provider, but I'm happy to re-open an issue there
instead if that makes sense.

[catsby]

Indeed this is confusing... I tried this out and found that the configuration is correctly updated (FOO remains there), the change is simply displayed ... oddly. I'll mark this as a core bug because I'm not sure why it's doing this. Nothing is immediately obvious to me looking at the resource code.

[joestump]

I suspect this could be fixed by simply changing config_vars from TypeList to TypeSet.

EDIT: To elaborate on this a bit more, the reason that the resource does the right thing while TF outputs both values being redone is because the delta calculated by TF is ignored by this snippet. When updating config vars the resource sets all old keys to nil and then overwrites/sets keys from the new values. Any old key that still has nil set is removed by the API. The diff output itself is handled entirely in TF. 99.9% sure switching to TypeSet will fix this after reading over the code.

[apparentlymart]

This issue is a limitation of the code that prints out the plan into the UI. The problem is that it just compares each distinct key one by one, and doesn't take into account things like lists, maps, and sets.

In this particular case, because the map as a whole is now <computed>, the config_vars.0.% key is the one that reflects that, and the config_vars.0.SECRET key doesn't exist in the planned new value at all, because a computed map has no real keys.

This'll be fixed after we implement #15180, which we hope to do either as part of the 0.12 release or shortly after, depending on how the rest of the 0.12 development goes (that is, it's a stretch goal).

[hashibot]

Hello! 🤖

This issue relates to an older version of Terraform that is no longer in active development, and because the area of Terraform it relates to has changed significantly since the issue was opened we suspect that the issue is either fixed or that the circumstances around it have changed enough that we'd need an updated issue report in order to reproduce and address it.

If you're still seeing this or a similar issue in the latest version of Terraform, please do feel free to open a new bug report! Please be sure to include all of the information requested in the template, even if it might seem redundant with the information already shared in this issue, because the internal details relating to this problem are likely to be different in the current version of Terraform.

Thanks!

[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.