Computed values within nested lists within nested sets are unset by the framework

[liamcervante]

Module version

v0.11.1

Relevant provider source code

PR reproducing the bug

Terraform Configuration Files

resource "tf6muxprovider_nested" "example" {
  set {
	id = "one"
	list {
	}
	list {
	}
  }
  set {
	id = "two"
  }
}

Debug Output

N/A, the error is reproduced in a test case in the PR

Expected Behavior

The test case in the PR should pass.

Actual Behavior

=== RUN   TestAccResourceNested
    nested_resource_test.go:11: Step 1/1 error: After applying this test step, the plan was not empty.
        stdout:
        
        
        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:
        
          # tf6muxprovider_nested.example will be updated in-place
          ~ resource "tf6muxprovider_nested" "example" {
                id = "XVlBzgba"
        
              - set {
                  - id = "two" -> null
        
                  - list {
                      - id = "iCMRAjWw" -> null
                    }
                  - list {
                      - id = "hTHctcuA" -> null
                    }
                }
              + set {
                  + id = "two"
        
                  + list {
                      + id = (known after apply)
                    }
                  + list {
                      + id = (known after apply)
                    }
                }
                # (1 unchanged block hidden)
            }
        
        Plan: 0 to add, 1 to change, 0 to destroy.
--- FAIL: TestAccResourceNested (0.46s)

Steps to Reproduce

1. Checkout the branch in terraform-provider-corner (or the forked repo)
2. TF_ACC=1 go test internal/tf6muxprovider/provider1/*.go

References

• Reproducing a bug with nested sets, lists and computed values terraform-provider-corner#89
• Plan Modifiers Not Executed Before Plan Computed-Only Unknown Marking #183
• Issues with Nested Set Attributes with PlanModifiers #293
• SetNestedAttributes plan does not like single nested compute null values #302

[bflad]

Hi @liamcervante 👋 Thanks for raising this.

I wonder if this may be resolved with #468 and v0.12.0, which was released yesterday. Under the hood, sets are a slice of elements similar to lists, but previously the framework would use path-based lookups and data setting as it traversed deeper into collection types. Trying to doing this with sets, which treat the whole value of the set element as part of the path, was problematic as underlying values would change from null to unknown, etc. The new release aligns plan modification with the underlying slice elements, so that class of issue should no longer be present.

I'm going to try rebasing the corner PR, since that repository just had its dependency upgraded, to see if maybe we resolved this. 👍

[bflad]

Hey again 👋

I was able to confirm in hashicorp/terraform-provider-corner#89 that the resource using terraform-plugin-framework@v0.12.0 was able to successfully plan immediately without difference after apply:

$ TF_ACC=1 go test -count=1 -run='TestAccResourceNested' -v ./internal/tf6muxprovider/provider1 
=== RUN   TestAccResourceNested
--- PASS: TestAccResourceNested (1.12s)
PASS
ok      github.com/hashicorp/terraform-provider-corner/internal/tf6muxprovider/provider1        2.195s

There may be other unknown issues with this sort of schema setup, so if you want to play with it more, I'll leave this issue open for you. Otherwise, if we don't hear anything back in a few days we will close this out and we can track any new details in a fresh issue. 😄

[liamcervante]

Hi Brian!

Thanks so much for this, yes I agree that this issue is fixed.

However, I think I've found another one. This can be reproduced with my latest commit to the same branch I used previously: liamcervante/terraform-provider-corner@f6f2037

Basically, emply blocks within nested lists are breaking now as the framework is setting the value for these nested blocks as null instead of an empty list. I think the issue is here, as the ModifyAttributePlanRequest isn't setting the Attribute[Config|Plan|State]. This in comparison to the set operation here which is setting those values.

I can leave this issue open tracking this, or file a new one. Which would you prefer? I could even have a go at fixing this myself as it seems relatively straightforward, but that might not be the process. Let me know!

[liamcervante]

Potential fix for the latest issue: #480

[liamcervante]

I have found another issue, but I think it's different enough that I will close this and create a new one.

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