Should we export `1.0` as an integer or a float?

[cartermp]

trafficstars

So this came up due to a fun subtle issue with an app.

Today, we emit 1.0 as 1 -- code here and you can observe this with a console span exporter or any backend.

However, 1.0 isn't an integer! This can complicate things as such:

• The first attribute sent to a backend has a float that's a whole number (no decimal places)
• The backend assigns the column/attribute/field type to be an integer since that's what the proto spec said it was
• Subsequent attribute values are sent to that backend and they aren't whole numbers, and so they come in as floats in the proto

Unless the backend has a way to widen numerical values, change the type, and/or create an additional column and alias the two with the same name, even though there are different values with different field types, it'll result in confusing behavior. A backend might truncate the decimal places since the type of the attribute is "locked" to an integer. Or it might error. Or something else.

So! What's the right behavior? Do we feel that we're emitting things correctly?

[legendecas]

~~I believe toAnyValue should transform the number values regarding the ValueType in the metric instrument descriptor, instead of Number.isInteger. This would make the transformation more stable over different number values over time.~~

Update: Seems like this only applies to the attribute values. I don't think there is a value type indicator we could facilitate to transform the value.