-
Notifications
You must be signed in to change notification settings - Fork 44
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
Revisit patchProposedNewForUnknownBlocks #2247
Comments
With this change it is safe to rerun go generate to vendor objchange.ProposedNew algorithm and its modification is made explicit by writing out the intentional patch. Revisiting the patch is tracked in #2247
With this change it is safe to rerun go generate to vendor objchange.ProposedNew algorithm and its modification is made explicit by writing out the intentional patch. Revisiting the patch is tracked in #2247
I think this was not limited to sets - a few other test cases also had failures around
In pulumi we can have unknown objects, without the containing collection being unknown - it HCL this is perhaps not expressible (at least I have not found a way to express this) - we were not representing these diffs correctly before the patch and not showing a diff at all there. |
I'm still concerned it's possible to write a provider that would panic under Pulumi with this but not under TF, but we can keep this around for a bit until we find a real example. |
Seems like we've rolled this out everywhere and it's ok. Perhaps just an academic possibility. Closing. |
Cannot close issue:
Please fix these problems and try again. |
#2060 introduced a patch (patchProposedNewForUnknownBlocks) to objchange.ProposedNew algorithm vendored from OpenTOFU. This patch solves a usability issue with planning bridged provider update changes, specifically confirmed for sets with unknown elements. There are however some residual concerns whether this is the right fix. We should investigate if we can accomplished the desired goals in a way not involving patching.
Concerns:
with the patch more unknowns are surfaced and pushed into provider code as part of PlanResourceChange; if provider authors write code against OpenTOFU/Terraform behavior they may ship code such as plan modifiers that does not expect these unknowns and will panic
cross-testing against OpenTOFU becomes more difficult when the behavior deviates intentionally
Alternatives:
Possibly the patch can be scoped tighter to sets
Perhaps the problem can be solved at the outer Pulumi level, such as ensuring that unknowns from config are preserved at the corresponding positions in the plan, without disturbing the shape of the data passed to provider code
References:
The text was updated successfully, but these errors were encountered: