hashicorp
CLI cost estimation should be in $##.## format, is showing $51.2407741935483864
Terraform Version
Terraform v0.13.0-rc1
Terraform Configuration Files
Any workspace with cost estimation enabled
Expected Behavior
Observed behavior: When running a plan from the Terraform CLI with cost estimation enabled, the results are returned as
Cost estimation:
Resources: 4 of 4 estimated
$51.2407741935483864/mo +$0.0
------------------------------------------------------------------------
Actual Behavior
Cost estimation:
Resources: 4 of 4 estimated
$51.24/mo +$0.00
------------------------------------------------------------------------
Steps to Reproduce
Run terraform plan from the CLI on a workspace with cost estimation enabled.
References
None found
This is a formatting difference against how Terraform Cloud displays cost estimates, which always shows dollar values with cents rounded to two places. The relevant code is here: https://github.com/hashicorp/terraform/blob/b5f4f9a96ec759b0233cd244984c4ba3097ab5f4/backend/remote/backend_common.go#L296
The Terraform Cloud API client library returns these values as strings, so we would need to parse them into numeric types and round them to two digits before display.
Looking into the (closed source) Terraform Cloud code, I notice that the formatting code used in the UI there is not just a straightforward round... it seems to have some special cases to deal with cases like very small amounts that can show up in small-scale deployments, so that e.g. 0.0000000001 doesn't get rounded down to zero, and it introduces commas to delimit thousands.
For consistency I expect we'll want to mimic what the Terraform Cloud UI is doing as closely as possible, so I'm reproducing the unit test cases from Terraform Cloud into a table here in case we want to use them as inspiration. This is derived from the test cases of the formatting function itself, but I've not yet looked at the specific call to this function in the cost estimation part of the UI, so I'm not sure whether the UI is letting the function decide on a number of decimal places automatically or if it's forcing it to be two.
| Input | Decimal Places | Result |
|---|---|---|
| 12345 | unspecified | '$12,345.00' |
| -12345 | unspecified | '-$12,345.00' |
| 0.0 | unspecified | '$0.00' |
| -0.0 | unspecified | '$0.00' |
| 987.65 | unspecified | '$987.65' |
| 98765432.1 | unspecified | '$98,765,432.10' |
| -98765432.1 | unspecified | '-$98,765,432.10' |
| 0.0000000001 | unspecified | $0.0000000001 |
| 0.00000000006 | unspecified | $0.0000000001 |
| -0.00000000006 | unspecified | '-$0.0000000001' |
| 12345 | 2 | '$12,345.00' |
| -12345 | 2 | '-$12,345.00' |
| 0.0 | 2 | '$0.00' |
| -0.0 | 2 | '$0.00' |
| 987.65 | 2 | '$987.65' |
| 98765432.1 | 2 | '$98,765,432.10' |
| -98765432.1 | 2 | '-$98,765,432.10' |
| 0.0000000001 | 10 | '$0.0000000001' |
| 0.00000000006 | 2 | '$0.00' |
| 0.00000000006 | 9 | '$0.00' |
| -0.00000000006 | 9 | '$0.00' |
| 0.00000000006 | 10 | '$0.0000000001' |
| -0.00000000006 | 10 | '-$0.0000000001' |
| 0.006 | 2 | '$0.01' |
| -0.006 | 2 | -$0.01 |
| 0.004 | 2 | '$0.00' |
| -0.004 | 2 | '$0.00' |
| 1234.123456 | 6 | '$1,234.123456' |
| 1234.123456 | 5 | '$1,234.12346' |
| 1234.123456 | 4 | '$1,234.1235' |
| 1234.123456 | 3 | '$1,234.123' |
| 1234.123456 | 2 | '$1,234.12' |
| -1234.123456 | 2 | '-$1,234.12' |
I'm just reproducing the test cases as they are written in the Terraform Cloud frontend code and so I don't know any rationale for any of the specific decisions here. If some of them feel odd then we could ask someone about it, but mainly my point here is that I think we should make the behavior as close as possible so that e.g. something doesn't show as "effectively free" in one place and nonzero in another, or use a different rounding mode, etc.
At time of writing, Terraform Cloud's UI code is configured to render cost estimation prices with maximum fraction digits set to 2, so we could follow that lead. These test cases are very useful to have as a basis for the behaviour!