Skip to content

Conversation

@jbardin
Copy link
Member

@jbardin jbardin commented May 8, 2025

Terraform expects that function calls always return consistent known results, because those functions may be called multiple times to reevaluate the same logical blocks of configuration. The group of functions which read from the filesystem however can't maintain this contract on their own, because changes in the filesystem will inevitably alter their results. This can pose a serious problem when the environment around Terraform changes between plan and apply, and parts of the configuration which Terraform must assume are static evaluate to different values. Changes in the values returned by filesystem functions result in apply-time errors ranging from incorrect data being stored, unexpected errors from resources blaming the provider for inconsistent values, or an outright crash when the internal state of Terraform is corrupted.

Provider defined functions always had this inherent possibility too, because they are executed outside of the control of the Terraform runtime. We developed a method for comparing the function results to ensure they are always consistent between calls, and between plan and and apply, but that was tied directly to the provider function calls. This PR adapts the functionality developed for provider functions to be used more generically for any function call (a lot of the changes here are just removing "Provider" from the data structure names to indicate that they are no longer provider-specific).

Because the function results data already needed to be stored in the plan, and passed around to where functions are instantiated throughout the code, it wasn't much of a stretch to hook that into the Scope call which builds out the builtin functions as well. The wrappers are a bit ugly, because cty.Function is not an interface, and the function implementations are hidden within a private struct field, so we have to pass along multiple layers of closures to get the wrapper to where it can actually be called.

Fixes #36184

Target Release

1.13.x

jbardin added 6 commits May 7, 2025 13:02
We need to abstract the function results verification to use internally
too, so start by moving it out of the providers code.
Remove "provider" from the function results fields since it's not going
to be exclusively used for providers any longer.
Create wrappers to inject function results verification into all the
filesystem function implementations.
@jbardin jbardin marked this pull request as ready for review May 8, 2025 17:06
@jbardin jbardin requested review from a team as code owners May 8, 2025 17:06
Copy link
Contributor

@mildwonkey mildwonkey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👼🏻 v pure

@jbardin jbardin merged commit 7c95129 into main May 9, 2025
14 checks passed
@jbardin jbardin deleted the jbardin/pure-file-funcs branch May 9, 2025 12:06
@github-actions
Copy link
Contributor

github-actions bot commented Jun 9, 2025

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 Jun 9, 2025
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.

panic when external changes cause a different expansion during apply

2 participants