Don't write ephemeral outputs to state #37821
Merged
+74
−42
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Don't backport until after 1.14 release.
Previously, the line
state.SetOutputValue(n.Addr, val, n.Config.Sensitive)was (I think) mistakenly outside of a surrounding conditional. This isn't actually causing any problems at the moment, because ephemeral outputs are actually disallowed in root outputs anyway, and only root outputs are written to state but is still an inconsistency.Also, Stacks and Test do allow root outputs to be ephemeral but for the moment don't record state files anywhere so also not an issue (yet).
This did discover an issue in Test though, as we do use the state file to check output values when requested which worked "by accident" before. Luckily, there is an easy fix for this which is to update the reference evaluator to use the named values object instead of the state file, and is safe to write ephemeral outputs into the named values since that is never made available externally. So, this PR also updates the GetOutput resolver to use the named values instead of the state file to resolve output references from test files.
Fixes #
Target Release
1.15.x
Rollback Plan
Changes to Security Controls
Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.
CHANGELOG entry