GetOk output for null string field and empty string field are identical making it impossible to tell if a value is to be un-set or ignored.

[dcaponi]

Not sure if bug or feature but this has been kinda frustrating. I have an API that accepts a string field, and as far as requests go, it is valid to send a payload without the field, the field as an empty string (to unset the existing value) and of course the payload with a string.

Passing a zero value such as an empty string to un-set a field is impossible to handle due to the GetOk function returning identical responses for a field set to "" and a field set to null or omitted entirely.

Am I doing this wrong or is handling values that are zero values in Go unsupported?

Terraform Version

Terraform v0.14.4

Terraform Configuration Files

resource "dummy_resource" "test1" {
  typeList_resource {
    strField = ""
    otherField = "stuff"
  }
}
resource "dummy_resource" "test2" {
  typeList_resource {
    otherField = "stuff"
  }
}
resource "dummy_resource" "test3" {
  typeList_resource {
    strField = "stuff"
    otherField = "stuff"
  }
}
...

Debug Output

Placing a logger on line 546 of resource_data.go inside the func (d *ResourceData) get(addr[]string, source, getSource) getResult {} method yields the following:

log.Println("Value:", result.Value, "zero_or_schema:" result.ValueOrZero(schema), "is nil?" result.Value == nil)

Value: <nil> zero_or_schema:  is nil? true           // test 1 - unexpected (expected is nil to be false and result.Value to be "")
Value: <nil> zero_or_schema:  is nil? true           // test 2 - expected (field omitted so should be nil)
Value: stuff zero_or_schema: stuff is nil? false.  // test 3 - expected (field present and has non-empty value)

Also logging output of GetOk("typeList_resource.0.strField) yields

GetOK:  false          // test 1 - unexpected (expected true since this field is set, but to the zero value for string)
GetOK:  false          // test 2 - expected (field not set so should get false for second variable)
GetOK: stuff true.  // test 3 - expected (field present and got true for second variable)

Crash Output

No Crash

Expected Behavior

Expected GetOk("typeList_resource.0.strField") to return "", true for the empty string and <nil> false for the missing field

Actual Behavior

GetOk("typeList_resource.0.strField") returns "", false in both cases. Now there's no way to tell which resource had the strField set to "" and which was missing entirely.

Steps to Reproduce

1. terraform init
2. terraform apply

Additional Context

N/A

References

None

[apparentlymart]

Hi @dcaponi,

It seems like you're talking about some features of the Terraform SDK here, rather than Terraform CLI/Core. If so, I'd suggest opening this issue in the SDK repository instead, where the team that maintains the SDK is more likely to see it.

With that said, I think what you're seeing here might be related to hashicorp/terraform-plugin-sdk#133, so I'd suggest reviewing that first to see if the discussion there corresponds with what you're seeing and whether the discussion includes some ideas for how to get a result more like what you expected. In particular, that discussion talks about GetOkExists, which I remember being an attempt to replace GetOk with functionality more like what I think you were expecting here, although I've not worked on the SDK for some years now so I may be misremembering.

(Most of that discussion in that issue happened when the SDK was still kept in a subdirectory of this repository, and so it includes some references to old issues and directories that might not match exactly anymore, but the principles should all still line up as the separate SDK version 2 still has the same ResourceData API that the formerly-in-this-repository SDK had.)

Since you are discussing a behavior of the SDK rather than of Terraform Core, I don't think there's anything we could change in this repository to address what you raised here, and so I'm going to close this. If you conclude that hashicorp/terraform-plugin-sdk#133 is talking about something different than what you've encountered, please do open an issue in the SDK repository where the SDK team should be able to give a more informed response. Thanks!

[dcaponi]

@apparentlymart Sounds good, I'll take this over there thanks!

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