terraform-plugin-sdk
terraform-plugin-sdk copied to clipboard
hashicorp
StateFunc cannot be used within a TypeSet in 0.12
If a provider is using Schema.StateFunc on an attribute of a set value, the resource will see extra entries in the set obtained from d.Get during Apply.
This is because the SDK is getting different values for the set between PlanResourceChange and ApplyResourceChange, and generating different hash values for the flatmap representation. This prevents the new protocol shims from being able to correlate the planned set values with the original config values, and they appear as separate set elements.
The recommended option here is to convert the TypeSet to a TypeList in the schema, which should behave the same in most respects, other than the inherent deduplication of identical config blocks which isn't usually a concern.
Migrating the state from the hashed value to the config value is a harder prospect, and will probably require manual intervention by the user, i.e. applying once without changing the config to save the new values.
This situation is not likely to have a remedy when using the legacy SDK with 0.12 or later, but I'm leaving the issue open here for provider developers that may encounter it during the upgrade process.
Run into this issue today, I made a repo to reproduce https://github.com/jerome-quere/terraform-provider-test
I hit this issue today. StateFunc is being used to json-normalize one of the fields before being stored in the set as a string value. If the normalization returns a string that differs by even one character then I get a defunct entry in the schema set with the original json in it and seemingly no other fields. If the normalization returns the exact same string then the bug does not occur.
In my case one of the other entries in the map that comprises the set entry is a required string so I can just check that it's not "" and ignore the set entry if it is. The state file stored on disk seems to have the correct entries so I don't get unexpected plan vs. infra changes.
