Bug (or at least misleading error message) in jsondecode function when there is duplicate keys in given json string

[erwan-simon]

Terraform Version

v1.10.4

Terraform Configuration Files

Does not work :

locals {
  test = jsondecode("{ \"hello\": { \"test\": true }, \"hello\": { \"test2\": false } }")
}

Works :

locals {
  test = jsondecode("{ \"hello\": { \"test\": true }, \"something_else_than_hello\": { \"test2\": false } }")
}

Debug Output

During plan or apply :

╷
│ Error: Error in function call
│
│   on terraform.tf line 2, in locals:
│    2:   test = jsondecode("{ \"hello\": { \"test\": true }, \"hello\": { \"test2\": false } }")
│     ├────────────────
│     │ while calling jsondecode(str)
│
│ Call to function "jsondecode" failed: unsupported attribute
│ "test".

Expected Behavior

The dupplicate key should overwrite the previous ones in the map, or at least the error message should state why is "test" unsupported.

Actual Behavior

It fails saying that "test" (the dupplicate key) is an unsupported attribute

Steps to Reproduce

1. terraform init
2. terraform plan

Additional Context

No response

References

No response

Generative AI / LLM assisted development?

No response

[crw]

Thanks for this issue report. I would imagine this would come from the upstream library provided by golang, it might be worth investigating whether there is an upstream bug for this issue. Thanks!

[jbardin]

Hi @erwan-simon,

Yes, the error is coming from an upstream library, though not the Go standard library, but rather the go-cty library used to handle the underlying type system in Terraform. The problem stems from Terraform (cty) being mostly statically typed, and trying to decode multiple values of different types into a single object key.

Because duplicate keys are conventionally tolerated in json decoding rather than failing, the decoding library attempts to override the first object encountered with the second, but it cannot decode the second object due to it having a different type -- {test=string} is distinct from {test2=string}.

That explains why the error is what it is, but you're right that is not a helpful error. We'll have to see if the upstream library can refactor the decoding a bit to give a more useful message.