-
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
Pass state back to the engine if Apply encountered an error #2695
Conversation
9be63d5
to
03b9498
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2695 +/- ##
==========================================
+ Coverage 69.47% 69.51% +0.04%
==========================================
Files 301 301
Lines 38644 38637 -7
==========================================
+ Hits 26847 26858 +11
+ Misses 10272 10259 -13
+ Partials 1525 1520 -5 ☔ View full report in Codecov by Sentry. |
03b9498
to
5978502
Compare
5978502
to
79e39da
Compare
79e39da
to
5ede56d
Compare
pkg/tfshim/sdk-v2/provider2.go
Outdated
@@ -349,7 +349,7 @@ func (p *planResourceChangeImpl) Apply( | |||
|
|||
resp, err := p.server.ApplyResourceChange(ctx, t, ty, cfg, st, pl, priv, meta) | |||
if err != nil { | |||
return nil, err | |||
return resp, err |
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.
Curious how does this type-check? resp is the result of ApplyResourceChange but the type is shim.InstanceState?
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.
Hm, ApplyResourceChange
returns a v2InstanceState2
which fulfils shim.InstanceState
and is the same type we create on the following line.
I wonder why we recreate it there. Thanks for spotting this.
EDIT: Seems entirely redundant - all the parameters created on the following line are identical to what is returned by ApplyResourceChange. I've simplified it
This PR has been shipped in release v3.97.0. |
In the SDKv2 bridge under PlanResourceChange we are not passing any state we receive during TF Apply back to the engine if we also received an error. This causes us to incorrectly miss any resources which were created but encountered errors during the creation process. The engine should see these as ResourceInitError, which allows the engine to attempt to update the partially created resource on the next up. This PR fixes the issue by passing the state down to the engine in the case when we receive an error and a non-nil state from TF during Apply. This is the second attempt at this. The first was #2695 but was reverted because it caused a different panic: #2706. We added a regression test for that in #2710 The reason for that panic was that we were now creating a non-nil `InstanceState` with a nil `stateValue` which causes the `ID` function to panic. This PR fixes both issues by not allowing non-nil states with nil `stateValue`s and by preventing the panic in `ID`. There was also a bit of fun with go nil interfaces along the way, which is the reason why `ApplyResourceChange` now returns a `shim.InstanceState` interface instead of a `*v2InstanceState2`. Otherwise we end up creating a non-nil interface with a nil value. related to pulumi/pulumi-gcp#2700 related to pulumi/pulumi-aws#4759 fixes #2696
In the SDKv2 bridge under PlanResourceChange we are not passing any state we receive during TF Apply back to the engine if we also received an error. This causes us to incorrectly miss any resources which were created but encountered errors during the creation process. The engine should see these as
ResourceInitError
, which allows the engine to attempt to update the partially created resource on the nextup
.This PR fixes the issue by passing the state down to the engine in the case when we receive an error and a non-nil state from TF during Apply.
related to pulumi/pulumi-gcp#2700
related to pulumi/pulumi-aws#4759
fixes #2696