c794bf5bcc
Previously we would construct a proposed new state with unknown values in place of any not-set-in-config computed attributes, trying to save the provider a little work in specifying that itself. Unfortunately that turns out to be problematic because it conflates two concerns: attributes can be explicitly set in configuration to an unknown value, in which case the final result of that unknown overrides any default value the provider might normally populate. In other words, this allows the provider to recognize in the proposed new state the difference between an Optional+Computed attribute being set to unknown in the config vs not being set in the config at all. The provider now has the responsibility to replace these proposed null values with unknown values during PlanResourceChange if it expects to select a value during the apply step. It may also populate a known value if the final result can be predicted at plan time, as is the case for constant defaults specified in the provider code. This change comes from a realization that from core's perspective the helper/schema ideas of zero values, explicit default values, and customizediff tweaks are all just examples of "defaults", and by allowing the provider to see during plan whether these attributes are being explicitly set in configuration and thus decide whether the default will be provided immediately during plan or deferred until apply. |
||
|---|---|---|
| .. | ||
| internal/planproto | ||
| objchange | ||
| planfile | ||
| action.go | ||
| action_string.go | ||
| changes.go | ||
| changes_src.go | ||
| changes_state.go | ||
| changes_sync.go | ||
| doc.go | ||
| dynamic_value.go | ||
| dynamic_value_test.go | ||
| plan.go | ||
| plan_test.go | ||