-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
stacks: error if provider emits deferred action when it's not supported #35118
Conversation
2af22f1
to
2567445
Compare
2567445
to
08917d1
Compare
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.
This all seems reasonable to me -- I'm guessing there should be some covering unit tests as well. 👍
Co-authored-by: Brian Flad <bflad417@gmail.com>
ce830b8
to
f684df8
Compare
I only added them sporadically since I felt like there would be too much clutter if I added them in general. If we feel like this does not give us enough security we can run every tests once with deferral allowed and once without to check this is handled consistently
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.
This looks good to me, I just had a question about the prior-errors check.
@@ -657,6 +665,12 @@ func (n *NodeAbstractResourceInstance) refresh(ctx EvalContext, deposedKey state | |||
}, | |||
}) | |||
|
|||
// If we don't support deferrals, but the provider reports a deferral and does not | |||
// emit any error level diagnostics, we should emit an error. | |||
if resp.Deferred != nil && !deferralAllowed && !resp.Diagnostics.HasErrors() { |
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.
Could you explain a bit more about the final check in this conditional, the one for no errors yet in the response diagnostics?
Is it just because... we're gonna be erroring anyway, and so who knows, maybe that incoherent provider response will resolve itself anyway once you fix the more urgent problem?
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 tools to build providers with (framework or sdk) do the same check in their implementation because they can provider a more detailed explanation what might have gone wrong to the user / provider developer. But providers can also be developed without helpers so in case this erroneous condition exists and no diagnostics have been emitted we want to provide this error to make sure users see at least and at most one error.
Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch. |
Fixes #
Target Release
1.8.x
Draft CHANGELOG entry
ENHANCEMENTS