CLI cost estimation should be in $##.## format, is showing $51.2407741935483864

[mikegreen]

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

[alisdair]

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:

terraform/backend/remote/backend_common.go

Line 296 in b5f4f9a

b.CLI.Output(b.Colorize().Color(fmt.Sprintf(" $%s/mo %s$%s", ce.ProposedMonthlyCost, sign, deltaRepr)))

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.

[apparentlymart]

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.

[alisdair]

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!