Description
In learning more about the Terraform protocol, it came up that when a value exists in a Terraform config, only two possible values can be set in that field's state:
- the exact, lexicographical representation that is entered into state
- the exact, lexicographical representation that is entered in the config
This applies even when a value is computed, and failure to adhere to this may break if the field changes and is interpolated into another resource, as the plan will not match what was applied. In our current SDK, we're mostly getting away with this. In the next SDK, we will not get away with this. So we should correct this for 3.0.0.
We mostly do this in areas where we use self_links or other values that have multiple, semantically equivalent forms. The proposed strategy we should be following is to do this canonicalization when setting the value in state. Basically, when we're about to update a value in state, check if it's semantically equivalent to the value in the config or in state, and not change it if it is. We should still DiffSuppress (to avoid two equivalent representations causing a spurious diff) but this should keep us in line with the Terraform protocol's expectations.