tfsdk: Allow GetAttribute To Return Unknown Values Instead Of Null When Missing Due To Parent Being Unknown

[bflad]

Module version

v0.4.2

Use-cases

As part of fixing #150, the GetAttribute() method on Config, Plan, and State will skip tftypes.ErrInvalidStep errors and instead return null values when valid, but missing. A related case of this behavior that might be useful for functionality such as plan modifiers and validation is knowing whether the value is instead unknown, which can happen if the value is missing from Config, Plan, or State because a parent path value is marked as unknown.

Attempted Solutions

Providers can verify if any parent paths are unknown, when a null value is returned. For example in attribute plan modifiers, the entire Config, Plan, or State value is available.

Proposal

Have the GetAttribute() method on Config, Plan, and State automatically perform the parent path checks for unknown. If found, return unknown value for type, otherwise continue returning null value for type.

References

• "step cannot be applied to this value" failure after before update if nested attribute was previously null #150
• tfsdk: Return null value when missing from Config, Plan, and State GetAttribute() method #185

[paddycarver]

I think we may also just want to complicate the errors returned by tftypes.WalkAttributePath to be more explicit about why a step is invalid.

[bflad]

Created hashicorp/terraform-plugin-go#113 upstream to noodle on that.

[bflad]

Another option here is limiting GetAttribute() and SetAttribute() to only allow a single AtName() path step for the path. That removes the possibility of getting an incorrect value state, since Terraform should always ensure that top-level attributes are always set correctly. This also would remove the current framework implementation complexity associated with switching to/from the terraform-plugin-go path system and transform data manipulation beyond that first "level".

Whether or not that means making that name parameter a string, path.PathStepAttributeName (confusing or verbose for provider code, I'm sure), or leaving it as path.Path is certainly debatable. We would not be able to change the existing tfsdk.Config, tfsdk.Plan, or tfsdk.State parameter implementation or limit its existing implementation due to 1.x compatibility promises, but it may be something to consider when thinking about #590 should new types be introduced.