Detecting undefined keys in terraform config files from custom provider code

Hi,

Introduction:
Current writing our own provider (SDWAN) we ran in an issue with sending enormous huge/deeply nested (json) structures, and troubles having values with default value (bool:false, int:0 …) send on json when omitempty in go structures. Removing omitempty forced us to actually set/configure keys many/many times more then we use/need/desire.

The solution we forsaw is using the x-nullable vendor extension in openapi tools for generating library, so using pointers to all objects, *int, *bool, *somestruct etc, which gives an extra dimension to actually detect is a value is set, or not. This works great until you try to implement this idea into terraform (our provider).

We try to detect if a key actually has been set in terraform configuration, from terraform provider code point of view. but i was not able to do so.
It seems terraform does no see any difference between not set/configured or set to the “default” value, bool: false, int: 0, string:""

We try to fill structures depening is a key is configured, pseudo code:
tf config file with most basic sample, of 3 situations:

alertsenabled = 1 # Default in SDWAN

alertsenabled = 0 # Default Int

commented just leaves the default, not having set the the value now/to accepted value

var ValueToProcessPtr *int // nill pointer by default

if d.CheckIfKeyHasBeenConfigured(“alertsenabled”) {
*ValueToProcessPtr = d.Get(“alertsenabled”)
}

<process data if ValueToProcessPtr != nill>, else ignore
<marshalling it into json will send ‘null’ if ValuePtr is not set and no omitempty is configured, or if Valueptr is not set and omitempty is defined the key is simply omitted. completely as expeceted.>

If some can shed some light on this issue (for us), please do so.
Ideas, on how we should do such thing, could also quite helpfull.

PS: using terraform 0.12.15 go1.13.7 and import “github.com/hashicorp/terraform/helper/schema
int our provider

Thanks in advance,

Arjan Filius

This is currently an unsolved problem in Terraform. There’s an issue describing some of the background on it.

This is, unfortunately, something that will need to wait for the SDK to be redesigned to use 0.12’s type system before providers can take advantage of it.