Number attributes not synthed as references

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave “+1” or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

cdktf & Language Versions

com.hashicorp:cdktf:0.9.0 “aws@~> 3.0” OpenJDK Runtime Environment (build 1.8.0_312-b10)

Affected Resource(s)

https://www.terraform.io/docs/providers/aws/r/memorydb_cluster https://www.terraform.io/docs/providers/aws/r/db_instance

Debug Output

Expected Behavior

db.port should synthesize to Terraform reference instead of number:

"value": "${aws_memorydb_cluster.cluster_9AC9C0F1.cluster_endpoint.0.port}"

This workaround can achieve the above:

db.getStringAttribute("port")

Actual Behavior

db.port synthesizes to:

"value": "-8.109562212591454E298"

Steps to Reproduce

I assume this happens for any provider when trying to synth number types.

Important Factoids

This seems to be a regression as I found #679 that was supposedly fixed in 0.6.0.

References

• #0000

[DanielMSchmidt]

Hey folks, sorry for taking so long, but I have found the problem.

During synth your program transforms the number to a sting with Gson. After that CDKTF runs through all the numbers it knows of and translates them to terraform expressions if applicable. But your number is not a number anymore, it’s a string now so we dont catch it. To solve this issue right now you can use Fn.jsonencode(testingResource) and it works.

The bigger question here is, can we make your current example work. I think we possibly can try to find things that look like numbers in all strings and see if they are known to us. For that we would need to check if a tokenized number can collide with another tokenized number if serialized to string. If we are sure this can not happen we can then search through every string for something that looks like a serialized number and replace this with the TF expression needed. The serialization format could vary between languages though, JS uses e+ instead of E like Java for example. It could also be a custom serialization engine being used. So I guess it’s hard to get right all the time, but getting it right most of the time and never getting it wrong would be sufficient I think

[marceloaguiarr]

Hello. I have created this repo to show the error happening. Hope that makes things more clear.

All you have to do is clone, then run the test class. It should print the synthesized string with the error. As you said, this really looks like a rounding error when the serialisation of the java class into json happens.