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

Backport of core: Don't re-register checkable outputs during the apply step into v1.3 #31903

Merged

Conversation

teamterraform
Copy link
Contributor

Backport

This PR is auto-generated from #31890 to be assessed for backporting due to the inclusion of the label 1.3-backport.

The below text is copied from the body of the original PR.


Once again we're caught out by sharing the same output value node type between the plan phase and the apply phase. To allow for some slight variation between plan and apply without drastic refactoring here we just add a new flag to nodeExpandOutput which is true only during the planning phase.

This then allows us to register the checkable objects only during the planning phase and not incorrectly re-register them during the apply phase. It's incorrect to re-register during apply because we carry over the planned checkable objects from the plan phase into the apply phase so we can guarantee that the final state will have all of the same checkable objects that the plan did.

This avoids a panic during the apply phase from the incorrect duplicate registration. This closes #31846.

@teamterraform teamterraform force-pushed the backport/b-check-output-multi-expand/broadly-whole-lark branch 2 times, most recently from 6450848 to 86bb52d Compare September 29, 2022 15:24
Once again we're caught out by sharing the same output value node type
between the plan phase and the apply phase. To allow for some slight
variation between plan and apply without drastic refactoring here we just
add a new flag to nodeExpandOutput which is true only during the planning
phase.

This then allows us to register the checkable objects only during the
planning phase and not incorrectly re-register them during the apply phase.
It's incorrect to re-register during apply because we carry over the
planned checkable objects from the plan phase into the apply phase so we
can guarantee that the final state will have all of the same checkable
objects that the plan did.

This avoids a panic during the apply phase from the incorrect duplicate
registration.
@apparentlymart apparentlymart force-pushed the backport/b-check-output-multi-expand/broadly-whole-lark branch from 86bb52d to 3e5f58f Compare September 29, 2022 15:26
@apparentlymart apparentlymart merged commit df9b3ff into v1.3 Sep 29, 2022
@apparentlymart apparentlymart deleted the backport/b-check-output-multi-expand/broadly-whole-lark branch September 29, 2022 15:35
@github-actions
Copy link

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

@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants