handle empty containers in ProposedNew NestedTypes#29580
Conversation
The CoerceValue code was not updated to handle NestedTypes, and while none of the new codepaths make use of this method, there are still some internal uses.
jbardin
added
the
1.0-backport
apparentlymart
left a comment
apparentlymart
left a comment
There was a problem hiding this comment.
This makes sense to me... I guess we inherited this from the codepath which handles blocks where we needed to preserve the rigid invarants the SDK expected for those, but that sort of mangling isn't correct for attributes.
The realization that this was likely the extra processing we had to do to make blocks work then led to the question I left inline, though if the answer to that is "no" (that is, if there's a reason to reconstruct new values rather than just preserve the existing ones) then I'm happy to keep it how you wrote it, though I'd love to know more about what that reason is for my own edification! 😀
Empty containers of NestedTypes were not handled in ProposedNew, causing plans to be submitted with null values where there was configuration present.
jbardin
force-pushed
the
jbardin/proposed-new-empty-containers
branch
from
e1c8fa7 to
331dc8b
Compare
jbardin
changed the base branch from
jbardin/coerce-value-nested-types
to
main
ghost
mentioned this pull request
|
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
Empty containers of NestedTypes were not handled in ProposedNew, causing plans to be submitted with null values where there was configuration present.
Fixes #29576