0.14.2
I would expect the output variable to simply set code to an "" empty string which was the case in Terraform 0.13
resources_json = {
"test" = {
...
"route53_redis_endpoint" = ""
"code" = ""
}
}
resources_json = {
"test" = {
...
"route53_redis_endpoint" = ""
"code" = tostring(null)
}
}
This happens when output has a value set from another module. By the looks of it, terraform doesn't evaluate the output to resolve the function tostring call.
@marcincuber thanks for reporting this! What would be really helpful here is a simple terraform config showing how you got here, ideally using null_resources so we don't have to provision real infrastructure as a toy test case. Is that something you can help provide?
@danieldreier Simple example:
main.tf
module "study" {
source = "./study"
}
output "test" {
value = module.study
}
study module contains the following:
variable "study_code" {
type = string
default = null
}
output "study_code" {
value = var.study_code
}
Result:
test = {
"study_code" = tostring(null)
}
Thanks @marcincuber! I've confirmed this on 0.14.2; thank you for reporting this. For convenience for the engineer who picks this up, I've copied the repro case to https://github.com/danieldreier/terraform-issue-reproductions/tree/master/27217
This looks like expected behaviour to me, and the behaviour in 0.13 was a bug. The value of the output is a null value of type string, which Terraform displays in human-readable output as tostring(null) to clarify the type of the null value.
Displaying a null string as "" would be incorrect, as they are different values.
Can you explain why this behaviour causes problems for you in practice?
@alisdair We are using Module's output by turning it into JSON object then pushing that to S3. Then another process it using that JSON object for other purposes. Certain values simply default to null which I would expect to be an empty string "". It worked like that in tf 0.12 and 0.13.
tostring(null) doesn't look like a correct output to me. However, it would be good to clarify what is the correct behaviour going forward. Another example behaving differently:
output "test_v2" {
value = {
test_object = {
test_2 = null
}
}
}
Outputs:
test_v2 = {
"test_object" = {
"test_2" = null
}
}
I don't understand why you expect a null string to be output as "". They're two different values. If you'd like the default value of your string variable to be an empty string, you can set that as the default. Perhaps I'm missing something obvious—if so please let me know.
I'm also unable to reproduce the behaviour you're describing in Terraform 0.12 and 0.13. For your last example, here's the output:
$ terraform-0.12.29 output
test_v2 = {
"test_object" = {}
}
$ terraform-0.13.5 output
test_v2 = {
"test_object" = {}
}
This was a bug, which caused object attributes with value null to be omitted from the human-readable output.
If you're looking for machine-readable consistent output, we recommend using the terraform output -json format rather than trying to parse the human-readable output. The machine-readable JSON output is unchanged across 0.12, 0.13, and 0.14:
{
"test_v2": {
"sensitive": false,
"type": [
"object",
{
"test_object": [
"object",
{
"test_2": "dynamic"
}
]
}
],
"value": {
"test_object": {
"test_2": null
}
}
}
}
Am I missing something?
To explain further, tostring(null) is our human-readable output for this value because it is the only concise way to create a null value of type string using HCL.
@alisdair thanks for the explanation. This is a desired behaviour as you said and I shall make changes in my code to handle tostring(null) values.
I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
Thanks @marcincuber! I've confirmed this on 0.14.2; thank you for reporting this. For convenience for the engineer who picks this up, I've copied the repro case to https://github.com/danieldreier/terraform-issue-reproductions/tree/master/27217