If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)
Issue details
Handling resources that have default values set on the service as a provider author can take some thought. A naive implementation can result in persistent diffs or refresh errors (ie due to the service read returning the explicit defaults which were not present in the inputs). I'm aware of 3 ways to handle defaults:
1) If the provider itself is supplying the defaults, or knows the values the service will supply, the provider can substitute in the defaults during Check
2) If the provider has to defer to the service to apply defaults, the provider can suppress diffs (and updates) when the user has left the property unset. This requires the user to explicitly set the value to "go back" to the defaults or set an explicit empty value to clear the field. This can be a confusing UX, but is often used as a way to handle settings that might be controlled by multiple resources. This makes the unset value semantically mean "leave this setting alone".
3) If don't want unset to mean "leave this setting alone", but you also don't know the value the server will set, you have to resort to hacks. The protocol does not let you see both the old inputs and old state at the same time to be able to distinguish whether a value in the outputs was set by the service or the client previously. It's possible, but risky to work around this limitation either by sneaking side channel information into the checked inputs or relying on the in memory state of the provider being persisted between Check and Diff in order to stash information about the old inputs. (Both of these techniques work to give the Diff access to enough information about old inputs to decide whether the unset field in the new inputs should be sent in an update.)
Because this can be tricky, we should write a small example provider that demonstrates the different options
Hello!
Issue details
Handling resources that have default values set on the service as a provider author can take some thought. A naive implementation can result in persistent diffs or refresh errors (ie due to the service read returning the explicit defaults which were not present in the inputs). I'm aware of 3 ways to handle defaults:
1) If the provider itself is supplying the defaults, or knows the values the service will supply, the provider can substitute in the defaults during
Check2) If the provider has to defer to the service to apply defaults, the provider can suppress diffs (and updates) when the user has left the property unset. This requires the user to explicitly set the value to "go back" to the defaults or set an explicit empty value to clear the field. This can be a confusing UX, but is often used as a way to handle settings that might be controlled by multiple resources. This makes the unset value semantically mean "leave this setting alone".
3) If don't want unset to mean "leave this setting alone", but you also don't know the value the server will set, you have to resort to hacks. The protocol does not let you see both the old inputs and old state at the same time to be able to distinguish whether a value in the outputs was set by the service or the client previously. It's possible, but risky to work around this limitation either by sneaking side channel information into the checked inputs or relying on the in memory state of the provider being persisted between
CheckandDiffin order to stash information about the old inputs. (Both of these techniques work to give theDiffaccess to enough information about old inputs to decide whether the unset field in the new inputs should be sent in an update.)Because this can be tricky, we should write a small example provider that demonstrates the different options
Affected area/feature