better determine when to plan optional+computed#32551
Conversation
We can check if an object in state must have at least partially come from configuration, by seeing if the prior value has any non-null attributes which are not computed in the schema. This is used when the configuration contains a null optional+computed value, and we want to know if we should plan to send the null value or the prior state.
jbardin
force-pushed
the
jbardin/optional-computed-null
branch
from
0462b84 to
8e917e5
Compare
| "obj": cty.ObjectVal(map[string]cty.Value{ | ||
| "optional": cty.StringVal("prior"), | ||
| "computed": cty.StringVal("prior computed"), | ||
| "list_obj": cty.NullVal(cty.List( |
There was a problem hiding this comment.
Should the comment on ll. 1992-1993 be removed?
"The entire prior nested value should be represented in the proposed new object if the configuration is null."
There was a problem hiding this comment.
ooh, that's a good catch! The result is good, let me check that it's what we actually want at this point in the stack of PRs though (this was broken up from a single huge PR).
There was a problem hiding this comment.
ok, this is the test I thought its was! updated the comment to describe the more accurate planning result.
|
Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch. |
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
2 participants
In the common cases we cannot determine if a null optional+computed value in the configuration was previously set when the value also exists in the state. There is however one situation where we can determine if there was previously a configuration value, we can check if a complex object in state must have at least partially come from configuration by seeing if the prior value has any non-null attributes which are not computed in the schema.