[sdk/python] Don't error on type mismatches when using input values for outputs #11422
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When resolving a resource's outputs, if an output value is missing (and it's not a preview), the SDK will see if there was an input prop of the same name as the output prop and use that input value as the value for the output. We do this across our SDKs. It can be problematic when the input prop's type isn't the same as the output prop's type. In the Python SDK, if the input value is a
dict
and the type of the output cannot be converted from adict
, then the SDK currently raises anAssertionError
, which causespulumi up
to fail. This is inconsistent with the other language SDKs, which don't error duringpulumi up
in such cases.This change changes the behavior of the Python SDK to not error when attempting to use an input value for the output value when there is a type mismatch. Instead of raising an error,
None
is returned, which is the same value that would be used if there had been no input value available to fill-in.Note that this behavior of filling in input values for missing output values has mostly worked OK for custom resources where there's generally a 1:1 match between inputs/outputs, but obviously it does not work well when that's not the case (which is likely to be more common now with components). We likely need to re-think this overall for all SDKs, as a separate, future change (i.e. having some way to opt-in to disabling this behavior).
Fixes #11416