-
Notifications
You must be signed in to change notification settings - Fork 9.5k
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
Coalescelist broken in 0.12 #25390
Comments
The real problem here is deeper. I noticed the above issue during a terraform destroy, where an output "dynamodb_table_name" {
value = element(
coalescelist(
aws_dynamodb_table.with_server_side_encryption.*.name,
aws_dynamodb_table.without_server_side_encryption.*.name
),
0
)
description = "DynamoDB table name"
} This works in terraform 0.11 but not in 0.12, where as a result of the destroy, both lists are empty, so terraform 0.12 aborts because there coalescelist aborts when all args empty lists. And I can see how semantically, this is the right thing to do for coalescelist: coalescelist is designed to return the first of its arguments that is not an empty list, so if they are all empty, it is probably reasonable that it should raise an exception. So I'm tempted to say that the real issue is 2 things:
Outputs on destroy:
Perhaps the use case of only some resources destroyed, via targetting. In that case, the outputs would be in I suppose the same situation could exist when you use So I think it should be possible for terraform to catch these 2 situations of outputs that cannot be resolved, and just warn, and continue instead of aborting. Problematic coalescelist: Real problem with coalescelist is that its behavior was changed drastically from 0.11 to 0.12. Instead, a new function say On a purely semantic level, it could be useful to have a However None would probably need to be very forgiving of operations on it, eg so you could write |
Hi @schollii! Thanks for reporting this. As I think you suspected, the change to the However, the interaction with the destroy phase (where a previously-sensible set of values suddenly become invalid) was of course not intentional, and I expect our efforts to address this will be focused on either not evaluating that output at all or evaluating it in a way that allows it to succeed during the destroy phase. The behavior you are seeing here reminds me of another issue #21096, but I can't be sure if these are related because your issue didn't include a trace log to indicate what phase of the destroy operation detected the error. If these issues both share a root cause then running If these two do share a root cause then that's good news, because we're currently looking into potential solutions to #21096 as a possible part of the next major release (still to be determined, based on the outcome of that research effort), and so that could potentially address both issues at once. Even if they don't share a root cause, they seem to have related symptoms -- Terraform evaluating something at an unsuitable time -- and so we may be able to address them both with a similar solution anyway. |
So @apparentlymart given your comment above and several issues my team has seen with tf destroy and output issue with version 0.12, what issue is tracking this work? Lots of issues on our side when we run destroy and the output command complaining about items not being there, which was never an issue before. So something with the functionality has changed and not in a good way. |
It's worth comparing the behavior of The pattern was usually: locals {
myvar = coalesce("", othervar_one, othervar_two)
} And if It would be great if |
Terraform Version
Terraform Configuration Files
With A and B both empty
Debug Output
Crash Output
Expected Behavior
Returns empty list
Actual Behavior
Tf aborts
Code that worked in 0.11 no longer works in 0.12.
Steps to Reproduce
Additional Context
References
The text was updated successfully, but these errors were encountered: