tfsdk: Check ProposedNewState for State differences before marking unknowns for Computed-only attributes in plans

[bflad]

Closes #181
Reference: https://github.com/hashicorp/terraform/blob/main/docs/resource-instance-change-lifecycle.md

ProposedNewState is the merged PriorState and Configuration. This allows us to verify if any configuration changes have occurred.

Previously, any Computed attributes would always trigger plan differences due to the unknown marking.

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # hashicups_order.edu will be updated in-place
  ~ resource "hashicups_order" "edu" {
      ~ id           = "1" -> (known after apply)
      ~ items        = [
          ~ {
            ~ coffee   = {
              + description = (known after apply)
                id          = 3
              ~ image       = "/nomad.png" -> (known after apply)
              ~ name        = "Nomadicano" -> (known after apply)
              ~ price       = 150 -> (known after apply)
              ~ teaser      = "Drink one today and you will want to schedule another" -> (known after apply)
            }
              # (1 unchanged attribute hidden)

            ~ coffee   = {
              + description = (known after apply)
                id          = 1
              ~ image       = "/packer.png" -> (known after apply)
              ~ name        = "Packer Spiced Latte" -> (known after apply)
              ~ price       = 350 -> (known after apply)
              ~ teaser      = "Packed with goodness to spice up your images" -> (known after apply)
            }
              # (2 unchanged attributes hidden)
          },
        ]
      ~ last_updated = "Tuesday, 28-Sep-21 11:53:27 EDT" -> (known after apply)
    }

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

This change limits the unknown marking to only be performed when there is actually a change between the ProposedNewState and State.

Without a configuration change:

No changes. Your infrastructure matches the configuration.

With a configuration change:

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # hashicups_order.edu will be updated in-place
  ~ resource "hashicups_order" "edu" {
      ~ id           = "1" -> (known after apply)
      ~ items        = [
          ~ {
            ~ coffee   = {
              + description = (known after apply)
                id          = 3
              ~ image       = "/nomad.png" -> (known after apply)
              ~ name        = "Nomadicano" -> (known after apply)
              ~ price       = 150 -> (known after apply)
              ~ teaser      = "Drink one today and you will want to schedule another" -> (known after apply)
            }
              # (1 unchanged attribute hidden)

            ~ coffee   = {
              + description = (known after apply)
              ~ id          = 1 -> 2
              ~ image       = "/packer.png" -> (known after apply)
              ~ name        = "Packer Spiced Latte" -> (known after apply)
              ~ price       = 350 -> (known after apply)
              ~ teaser      = "Packed with goodness to spice up your images" -> (known after apply)
            }
              # (2 unchanged attributes hidden)
          },
        ]
      ~ last_updated = "Tuesday, 28-Sep-21 11:53:27 EDT" -> (known after apply)
    }

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

As a followup, it may be necessary to invoke two passes of attribute and resource plan modifiers to ensure any changes captured by those modifiers triggers the unknown marking. As it stands now, a plan with no configuration changes, but changes due to plan modifiers will not correctly trigger the unknown marking. See also: #183

[bflad]

Some additional breadcrumbs for review, since the real change was just adding && !plan.Equal(state)

[bflad]

This is a test fix since the configuration contained it, so the proposedNewState would also contain it.

[bflad]

This is a test fix since the proposed new state contained it, so the planned state would also contain it.

[bflad]

NB: This was renamed to three_nested_computed_nested_configuration_change as seen below the next Git diff, just to capture the additional nuance between the two new test cases and the original.

[bflad]

Additional attribute on this resource to allow us to further verify plan unknown marking, since this resource has attribute plan modifiers and allowed me to catch #183 for the future. It does not have to be part of this pull request though. 😄

[kmoe]

Getting a slightly unexpected result with this.

Configuration:

provider "hashicups" {
  username = "education"
  password = "test123"
  host     = "http://localhost:19090"
}

resource "hashicups_order" "edu" {
  items = [{
    coffee = {
      id = 3
    }
    quantity = 2
    }, {
    coffee = {
      id = 2
    }
    quantity = 2
    }
  ]
}

Steps

1. Run terraform apply and proceed with yes
2. Change the second coffee id to 1
3. Run terraform apply and proceed with yes

Result

The output from the second apply is as in the PR description, but when actually running the apply we get this:

  Enter a value: yes

hashicups_order.edu: Modifying... [id=1]
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to hashicups_order.edu, provider
│ "provider[\"registry.terraform.io/hashicorp/hashicups\"]" produced an unexpected new value: .items: was
│ cty.ListVal([]cty.Value{cty.ObjectVal(map[string]cty.Value{"coffee":cty.ObjectVal(map[string]cty.Value{"description":cty.UnknownVal(cty.String),
│ "id":cty.NumberIntVal(3), "image":cty.UnknownVal(cty.String), "name":cty.UnknownVal(cty.String),
│ "price":cty.UnknownVal(cty.Number), "teaser":cty.UnknownVal(cty.String)}), "quantity":cty.NumberIntVal(2)}),
│ cty.ObjectVal(map[string]cty.Value{"coffee":cty.ObjectVal(map[string]cty.Value{"description":cty.UnknownVal(cty.String),
│ "id":cty.NumberIntVal(2), "image":cty.UnknownVal(cty.String), "name":cty.UnknownVal(cty.String),
│ "price":cty.UnknownVal(cty.Number), "teaser":cty.UnknownVal(cty.String)}),
│ "quantity":cty.NumberIntVal(2)})}), but now null.
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Edit: This error on apply also happens with main and v0.4.1. I'm not sure why .items is being set to null.

Edit 2: This appears to be a bug in the hashicups provider or server.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.