Diffs: going from zero value to nil

[vancluever]

The current diff logic does not currently account for a transition from a zero value to a nil state. This can be seen here, in that any nils returned during the diff process (in the config layer, specifically) do not get treated as nils, but converted to that type's zero value.

This creates problems like diffs being completely ignored for primitive transitions including, but not limited to:

false => nil
0 => nil
"" => nil

The first two are the most significant, as there has been plenty of precedent that these states are necessary in Terraform where a nil state has meaning, possibly instructing an API to disable a feature or configure it to inherit settings from a parent subsystem, and is why GetOkExists was exposed - which currently has its own issues, see hashicorp/terraform#17557. These two issues combined basically mean that a nil state only has meaning in a resource if the intention is to never move away from the nil state, which is a one-way trip that can't be reverted without state hacking.

As a note, both of these issues will be addressed in future releases (namely with the advent of HCL2, as mentioned in hashicorp/terraform#17557). This is mainly just a note to ensure there is a TODO to make sure the diff shortcomings are addressed.

[jakubpech]

Hi,
any news regarding this issue? From the other related issues I found, I understand that the proper implementation of nils requires backward-incompatible changes in SDK. Are there any plans to release V2 SDK, which will use protocol 5 only?

We came to the point in our provider, where we can hardly move forward without the nils and we need to implement some exotic workarounds for the deeply nested data structures. The question is how long we'll need to support these workarounds and how dirty they can be. Do you think there is a chance to have it released in the next 3 months?

Our provider was written in a 0.12+ era so we don't have any historical dependencies. Is there some SDK feature branch (version2?), where we can more or less safely use protocol 5 at our own risk? All we need right now is to prevent that SDK will change all our nils to default values.

[paultyng]

v2 (currently in dev on the version2 branch) will hopefully be released in the next few months. It will not contain exposure of the underlying type system yet, but that is one of the early goals to surface it more directly. v2 is protocol 5 only, but the goal with it is still largely to remain backwards compatible for existing provider codebases (but not necessarily for protocol) so we can start to add these features. The main features launching in v2.0 will be the binary test framework, usage of context, and better diagnostic support, but the type enhancements are on the short list for future minor releases.

The best tracking issue is probably #261, so going to merge that, as it proposes exposing lossless type information to the provider.

[ghost]

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.