SetNested objects with Computed attributes produce plan errors in 1.5.0

[chrismarget]

Terraform Version

Terraform v1.5.0
on darwin_amd64

Terraform Configuration Files

terraform {
  required_providers { setnested = { source = "chrismarget/setnested" } }
}

resource "setnested_problem" "x" {
  sna = [
    { required_string = "foo" },
    { required_string = "bar" },
  ]
}

Debug Output

terraform 1.5.0 failure gist
terraform 1.4.6 success gist

Expected Behavior

When executing terraform plan, a plan like this should have been generated (this example from Terraform 1.4.6):

Terraform will perform the following actions:

  # setnested_problem.x will be created
  + resource "setnested_problem" "x" {
      + sna = [
          + {
              + computed_int    = (known after apply)
              + required_string = "bar"
            },
          + {
              + computed_int    = (known after apply)
              + required_string = "foo"
            },
        ]
    }

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

Actual Behavior

Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: Provider produced invalid plan
│ 
│ Provider "registry.terraform.io/chrismarget/setnested" planned an invalid value for setnested_problem.x.sna: count in plan (cty.UnknownVal(cty.Number))
│ disagrees with count in config (cty.NumberIntVal(2)).
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵

Steps to Reproduce

1. clone the skeleton provider which reproduces this issue.
2. build the provider and make your terraform aware of it (dev_overrides?)
3. cd demo
4. terraform plan

Additional Context

Ultimately, this comes down to the SetNestedAttribute having a Computed: true attribute within.

Until 1.5.0, this pattern seemed to be okay (well, at least since v1.2, maybe longer than that.)

If this pattern really isn't okay, I'd like to understand the limits better, and I'll re-work my providers to ensure I don't repeat this problem.

But maybe it's a bug? (fingers crossed over here) It's hard for me to understand why terraform is reporting that the count of set elements is the problem here. I mean... Set elements can still be counted without dereferencing individual elements, right?

There's a discussion (hi @bflad and @jbardin) on the Hashicorp Discuss server here.

References

No response

[jbardin]

Thanks @chrismarget, I see the discrepancy now!

The upstream go-cty package is not consistent here. We changed the check to deal with unknowns so as to not panic when the set was unknown as a whole, but that now runs into this problem:

fmt.Printf("Length: %#v\nLengthInt: %d\n", set.Length(), set.LengthInt())
// Length: cty.UnknownVal(cty.Number)
// LengthInt: 2

This is where the new unknown is originating. I was assuming you hit this error because the entire set needed to be unknown due to the provider's internal handling, but this really is only the length check which is a problem here.

[github-actions]

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.