-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Computed values within blocks that are nested within set blocks are unset by the framework #483
Comments
Some other observations. If you replace the resource with any of the following the test works fine: resource "tf6muxprovider_nested" "example" {
set {
id = "one"
list {
}
list {
}
}
set {
id = "two"
}
} resource "tf6muxprovider_nested" "example" {
set {
list {
}
list {
}
}
set {
}
} resource "tf6muxprovider_nested" "example" {
set {
id = "one"
list {
id = "one"
}
list {
id = "two"
}
}
set {
}
} The last case needs the inner id to be set to optional as well as some other tweaks. But the point I think is that there's some weird behaviour around nested computed values and when it does or doesn't have to compute values for them. |
The actual error message originates here: https://github.com/hashicorp/terraform-plugin-framework/blob/main/internal/fwserver/server_planresourcechange.go#L296 But if you jump back up the stack and inspect the execution during the test, it seems like the computed values for the inner nested block (list) are appearing as null (even though the provider logic sets them), while all the other computed values are being set as normal: https://github.com/hashicorp/terraform-plugin-framework/blob/main/internal/fwserver/server_planresourcechange.go#L160 |
I'm curious how this hasn't been more of an issue until now, but the The testing for that function is a little heavy as it prefers to setup everything in a single, big schema with a single, big value. Ideally that testing would be converted to the parallel unit testing setup used elsewhere and where each test case can include its own smaller schema and values. I'm not sure when we'll have time to potentially fix or review a fix for this, but please use 👍 on the issue if you are also running into this to help with prioritization. |
I think I'm running into this writing a new resource for the AWS provider (hashicorp/terraform-provider-aws#27857). The schema includes an optional list within a required set (simplified below for brevity). Blocks: map[string]tfsdk.Block{
"control_mapping_sources": {
NestingMode: tfsdk.BlockNestingModeSet,
MinItems: 1,
Attributes: map[string]tfsdk.Attribute{
// omitted
},
Blocks: map[string]tfsdk.Block{
"source_keyword": {
NestingMode: tfsdk.BlockNestingModeList,
MinItems: 0,
MaxItems: 1,
Attributes: map[string]tfsdk.Attribute{
// omitted
},
},
}, Tests pass if
However, the suggestion above around passing through the value for if errors.Is(err, tfsdk.ErrPathIsBlock) {
// ignore blocks, they cannot be computed
logging.FrameworkTrace(ctx, "attribute is a block, not marking unknown")
return val, nil
} If this sounds like a reasonable solution, I'd be happy to get a PR started and take a shot at adding tests. Plugin SDKv2 presents separate challenges with nested computed attributes for this resource, so it'd be valuable to us to unblock use of framework here. |
I believe this has been resolved at least in v0.17.0, but please reach out if it has not. 👍 |
Just closing the loop here - I can confirm this has been fixed for my use case. Thanks! |
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. |
Module version
Relevant provider source code
PR reproducing the bug
Terraform Configuration Files
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
Steps to Reproduce
References
The text was updated successfully, but these errors were encountered: