Skip to content
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

Merged
merged 3 commits into from
May 7, 2024

Conversation

DanielMSchmidt
Copy link
Collaborator

@DanielMSchmidt DanielMSchmidt commented May 6, 2024

Fixes #

Target Release

1.8.x

Draft CHANGELOG entry

ENHANCEMENTS

  • stacks: if a provider uses deferred actions while terraform does not support this we will emit a diagnostic

@DanielMSchmidt DanielMSchmidt force-pushed the consistency-provider-deferred branch 2 times, most recently from 2af22f1 to 2567445 Compare May 6, 2024 11:49
Copy link
Member

@bflad bflad left a 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. 👍

internal/plans/deferring/deferred.go Outdated Show resolved Hide resolved
Co-authored-by: Brian Flad <bflad417@gmail.com>
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
Copy link
Collaborator

@nfagerlund nfagerlund left a 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() {
Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

@DanielMSchmidt DanielMSchmidt merged commit f3764ea into main May 7, 2024
10 checks passed
Copy link

github-actions bot commented May 7, 2024

Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants