-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix unknown collections of obj #2061
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2061 +/- ##
==========================================
- Coverage 60.74% 59.83% -0.92%
==========================================
Files 353 354 +1
Lines 46146 46183 +37
==========================================
- Hits 28032 27633 -399
- Misses 16559 17002 +443
+ Partials 1555 1548 -7 ☔ View full report in Codecov by Sentry. |
These tests were not failing last week, will take a look. |
This reverts commit fc38c75.
I've adapted this to keep the old behaviour for sdkv1 and make unknowns better in sdkv2 |
@@ -29,6 +29,20 @@ import ( | |||
"gotest.tools/assert" | |||
) | |||
|
|||
func resNeedsUpdate(res *schema.Resource) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The for
loop doesn't do anything here. It only has conditional continue
statements. If we don't need to check the value of fields, we should remove the for
loop and just return res.UpdateContext == nil
. Otherwise we need to make sure that resNeedsUpdate
is under test for whatever functionality it supports.
This PR has been shipped in release v3.88.0. |
This changes the bridge to correctly return unknowns for objects and collections in sdkv2.
fixes #1885
fixes #2032
stacked on #2158
Confirmed that TF sdkv2 supports both unknown blocks and unknown collections of blocks, so we should be fine to pass these into TF providers.
The TF sdkv1 does not support unknowns for blocks and collections so we keep the old behaviour of passing empty/ collection of unknown.
This returns
"lifecycle_rule":cty.UnknownVal(cty.List(cty.Object))
Our handling of collections containing unknowns and unknown collections is significantly better:
Unknown collections:
before:
after:
Note that the array being output as an
output<string>
is an engine limitation.Nested unknown collections:
before:
after:
The unknown was being put one level lower than it should be.
Quite a few other very wrong outputs in #2140, including diff duplications, missing diffs etc.