[sdk/python] Don't error on type mismatches when using input values for outputs #11422
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…or outputs 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. This can be problematic when the input prop's type isn't the same as the output prop's type. If the input value is a `dict` and the type of the output cannot be converted from a `dict`, then the SDK currently raises an `AssertionError`, which causes `pulumi up` to fail. This is inconsistent with the other language SDKs, which don't error during `pulumi 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.
Changelog[uncommitted] (2022-11-21)Bug Fixes
|
danielrbradley
approved these changes
Nov 21, 2022
|
bors merge |
bors bot
added a commit
that referenced
this pull request
Nov 21, 2022
11422: [sdk/python] Don't error on type mismatches when using input values for outputs r=justinvp a=justinvp 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 a `dict`, then the SDK currently raises an `AssertionError`, which causes `pulumi up` to fail. This is inconsistent with the other language SDKs, which don't error during `pulumi 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 Co-authored-by: Justin Van Patten <jvp@justinvp.com>
|
Build failed: |
|
bors retry |
|
Build succeeded: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
dictand the type of the output cannot be converted from adict, then the SDK currently raises anAssertionError, which causespulumi upto fail. This is inconsistent with the other language SDKs, which don't error duringpulumi upin 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,
Noneis 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