YAML numbers (unquoted) starting with 0 come to Terraform object string field as 1122 instead of what was typed

[hypnotisttom]

Describe the Bug

Using a terraform object with a string field, if I then set the string field value in the catalog to a number starting with 0 (in this case, it was an address object, and this field is the zip code), atmos seems to think the field value is 1122 instead of 08989, for example. If I quote the 08989, it works. If I do a "describe component" for the unquoted number, atmos indicates the 1122 was specified in the yaml file when it wasn't.

Not as urgent as I have a workaround. Just wanted to report the finding.

Expected Behavior

I would expect the 08989 (in this example) to be the value passed to the terraform component, just like it does if the number was 12345 (not starting with 0).

Steps to Reproduce

1. Create a terraform variable object that contains at least one string field (I have not tested this with a type=string, only a type=object({ zip_code = string})
2. Set up the catalog yaml to send an unquoted 5-digit number beginning with 0 as the value for this field
3. Run "atmos describe component" and see that atmos thinks 1122 is what was configured

I should note that I found this because I added a 5-digit validation rule to the terraform component, and terraform said it only got 4 digits. Digging further is how I found the 1122.

Screenshots

No response

Environment

No response

Additional Context

No response

[aknysh]

@hypnotisttom thanks again!.

Note that this is not an Atmos issue, this is how YAML behaves.

https://github.com/stoplightio/spectral/issues/1345

Before it even gets to Atmos code and then to Terraform, the YAML parser thinks that the unquoted string is a number and removes the leading zero from it (so Atmos does ot know anything about the type and can't do anything about it).

According to Core schema , 0125487936 would indeed not be a string but a number. Would you ensure it to be parsed as a string, surrounding it with double quotes should do the trick.

In summary, it's better to always quote ALL strings - fewer errors but prob less readable YAML code

[hypnotisttom]

Thanks @aknysh! I was confused as to why Atmos was showing 1122 as the number when I did something like 08989. Shouldn't "atmos describe component" have shown 8989 then if it is just dropping the 0, or am I misunderstanding? I was surprised "atmos describe component" showed the 4 digits different from the number after dropping the 0.

[osterman]

Closing this since it's expected behavior. We should probably add a page to atmos docs like this:

https://www.elastic.co/guide/en/beats/metricbeat/current/yaml-tips.html#avoid-leading-zeros