Error Generating Breakdown with v0.10.35

[DavidHaasz]

When attempting to run a Infracost breakdown using v0.10.35 it resulted in a report with no resources and therefore no costs.

Attempting to run within the --debug-report flag resulted in the following Go routine error and no report being generated

[
2024-04-10T10:32:30+01:00 DBG IsCloudEnabled inferred from Config.EnabledDashboard is_cloud_enabled=false,
�[91mError:�[0m An unexpected error occurred

bytes.Buffer.WriteTo: invalid Write count
goroutine 1 [running]:
runtime/debug.Stack()
	/opt/hostedtoolcache/go/1.22.1/x64/src/runtime/debug/stack.go:24 +0x5e
main.Run.func1()
	/home/runner/work/infracost/infracost/cmd/infracost/main.go:78 +0xb4
panic({0x29e26e0?, 0x3b30380?})
	/opt/hostedtoolcache/go/1.22.1/x64/src/runtime/panic.go:770 +0x132
bytes.(*Buffer).WriteTo(0xc0004c9d70, {0x3b36100?, 0xc000099010?})
	/opt/hostedtoolcache/go/1.22.1/x64/src/bytes/buffer.go:263 +0xee
github.com/rs/zerolog.ConsoleWriter.Write({{0x3b36100, 0xc000099010}, 0x1, {0x33dac7f, 0x19}, {0xc00024f080, 0x4, 0x4}, {0x0, 0x0, ...}, ...}, ...)
	/home/runner/go/pkg/mod/github.com/rs/zerolog@v1.31.0/console.go:145 +0x5c5
github.com/rs/zerolog.LevelWriterAdapter.WriteLevel(...)
	/home/runner/go/pkg/mod/github.com/rs/zerolog@v1.31.0/writer.go:27
github.com/rs/zerolog.(*Event).write(0xc000499a40)
	/home/runner/go/pkg/mod/github.com/rs/zerolog@v1.31.0/event.go:80 +0x103
github.com/rs/zerolog.(*Event).msg(0xc000499a40, {0x347255b, 0x34})
	/home/runner/go/pkg/mod/github.com/rs/zerolog@v1.31.0/event.go:151 +0x21a
github.com/rs/zerolog.(*Event).Msg(...)
	/home/runner/go/pkg/mod/github.com/rs/zerolog@v1.31.0/event.go:110
github.com/infracost/infracost/internal/config.(*RunContext).IsCloudEnabled(0xc0001209a0)
	/home/runner/work/infracost/infracost/internal/config/run_context.go:267 +0xfe
main.loadGlobalFlags(0xc0001209a0, 0xc000554008)
	/home/runner/work/infracost/infracost/cmd/infracost/main.go:358 +0x9c
main.newRootCmd.func1(0xc000554008, {0x3396273?, 0x4?, 0x3396233?})
	/home/runner/work/infracost/infracost/cmd/infracost/main.go:156 +0x2b7
github.com/spf13/cobra.(*Command).execute(0xc000554008, {0xc0004c9ce0, 0x3, 0x3})
	/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.4.0/command.go:835 +0x5c3
github.com/spf13/cobra.(*Command).ExecuteC(0xc0004fc588)
	/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.4.0/command.go:974 +0x38d
github.com/spf13/cobra.(*Command).Execute(...)
	/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.4.0/command.go:902
main.Run(0x0, 0x0)
	/home/runner/work/infracost/infracost/cmd/infracost/main.go:96 +0x186
main.main()
	/home/runner/work/infracost/infracost/cmd/infracost/main.go:40 +0x1f4

Environment:
Infracost v0.10.35+v0.10.35-v0.10.35

An unexpected error occurred. We've been notified of it and will investigate it soon. If you would like to follow-up, please copy the above output and create an issue at: �[4;1mhttps://github.com/infracost/infracost/issues/new�[0m,
2024-04-10T10:32:30+01:00 DBG 'POST' request to '/event' using trace_id: '3c470c26-a602-4ccc-a8c3-dcfde181b654',

One thing I did notice about the project that this occurred on it was using some community providers such as
postgresql = { source = "cyrilgdn/postgresql" version = "1.20.0" } as the projects that were just using Hashicorp providers seemed to work without issue or is this just a coincidence?

[vdmgolub]

Hello! Thank you for creating the issue!

Indeed --debug-report flag causes an error. We'll look into this. I've created a separate ticket to track that: #3011.

For the custom provider, you are right, Infracost doesn't support that. It only supports AWS/Azure and Google providers.
You can run the breakdown command with INFRACOST_LOG_LEVEL=debug env var and see the output. It should show a line like Unsupported provider postgresql.

Could you please clarify that your repo has only this community provider and nothing else? CLI should correctly evaluate aws/azure/google stuff and show their breakdown, but ignore the unsupported ones.

[DavidHaasz]

Thank you for the timely response!
So after adding INFRACOST_LOG_LEVEL=debug and re-running the breakdown command there is quite a lot of output to digest one notable of which I noticed was

2024-04-10T12:03:50+01:00 DBG evaluated outputs are the same as prior evaluation, exiting and returning expanded block module_name=root module_path=. module_source= parser_path=. project_name= project_path=. provider=terraform_dir
2024-04-10T12:03:50+01:00 DBG fetching attribute value attribute_name=source block_name=module.consumer_manager_alarm project_name= project_path=. provider=terraform_dir
2024-04-10T12:03:50+01:00 DBG using path '' for module 'module.consumer_manager_alarm' based on key 'consumer_manager_alarm' module_name=root module_path=. module_source= parser_path=. project_name= project_path=. provider=terraform_dir
2024-04-10T12:03:50+01:00 DBG failed to load module module.consumer_manager_alarm ignoring error="missing module with source 'registry.terraform.io/../modules/alarm ../modules/alarm' -  try to 'terraform init' first" module_name=root module_path=. module_source= parser_path=. project_name= project_path=. provider=terraform_dir

so for references /modules/alarm is a local module for the terraform project but if I am reading correctly Infracost is attempting to get that from the central registry which I don't believe is correct. This has repeated for all of the other modules as well which has probably want has resulted in 0 cloud resources being found

The structure of the project is most of the resources themselves are in modules with the main.tf bringing in those modules and passing the required parameters to create the infrastructure

I did also confirm that terraform init was run prior to running the breakdown command

[vdmgolub]

Interesting. Is it possible to create a minimal TF example that we could use to reproduce it?

[DavidHaasz]

Hi I will look to see if I can create a minimal one with a subset of the resources we are using. Would you need any config such as backends setup? or simply a TF project mirroring the folder structure that I have?

In the interim I have copied the entire debug output which have attached which may provide some further insights did see on a second run these lines which I wasn't sure what they meant

2024-04-10T13:31:10+01:00 DBG cannot create references from *hclsyntax.LiteralValueExpr as it is a literal value and will not contain refs attribute_name=alias block_name=module.kms_consumer_password_reset project_name= project_path=. provider=terraform_dir
2024-04-10T13:31:10+01:00 DBG cannot create references from *hclsyntax.LiteralValueExpr as it is a literal value and will not contain refs attribute_name=source block_name=module.kms_consumer_password_reset project_name= project_path=. provider=terraform_dir
2024-04-10T13:31:10+01:00 DBG cannot create references from *hclsyntax.LiteralValueExpr as it is a literal value and will not contain refs attribute_name=queue_name block_name=module.alsf_consumer_password_changed project_name= project_path=. provider=terraform_dir

infracost-breakdown-log-output.txt

[vdmgolub]

Thank you! Let's start with just the TF code and we'll go from there :)

[DavidHaasz]

Sorry meant to get back to this. I also did some ruling out of issues running locally by adding the infracost calls as step within a Bitbucket Pipeline am using here is the pipeline step for context

- step: &estimated-cost-comparison
        name: Run Infracost to check costs and policies
        image: infracost/infracost:ci-0.10
        runs-on:
          - self.hosted
          - global
        artifacts:
          - infracost.json
        script:
          # Clone the base branch of the pull request (e.g. main/master) into a temp directory.
          - git clone https://$BITBUCKET_AUTO_USERNAME:$BITBUCKET_AUTO_APP_PW@bitbucket.org/$BITBUCKET_REPO_FULL_NAME --branch=$BITBUCKET_PR_DESTINATION_BRANCH --single-branch /tmp/base
          # Generate an Infracost cost estimate baseline from the comparison branch, so that Infracost can compare the cost difference.
          - infracost breakdown --path=/tmp/base/dev --format=json --out-file=infracost-base.json --usage-file=/tmp/base/dev/estimated-usage.yml
          # Generate an Infracost diff and save it to a JSON file
          - infracost diff --path=./dev --compare-to=infracost-base.json --format=json --out-file=infracost.json --usage-file=./dev/estimated-usage.yml
          # Posts a comment to the PR using the 'update' behavior. This creates a single comment and updates it.
          - infracost comment bitbucket --path=infracost.json --repo=$BITBUCKET_WORKSPACE/$BITBUCKET_REPO_SLUG --pull-request=$BITBUCKET_PR_ID --bitbucket-token=$BITBUCKET_AUTO_USERNAME:$BITBUCKET_AUTO_APP_PW --behavior=update

and that has worked for the project in question which has produced a comment on the PR I have made which looks as follows

but when running same commands locally still get the original issue. Just wondering if anything else I should be checking

[vdmgolub]

No worries at all! :) Thank you for the provided info! The pipeline looks correct to me. 👍

So what I'd expect from the run:

1. If the project has only the cyrilgdn/postgresql provider and its resources, the estimate would be empty as Infracost doesn't support such a provider.
2. If in addition to the custom provider resources the project has resources from aws/azure/google providers, they should be evaluated fine and it would result in an estimate with some costs.

Looking at the screenshot it seems to work as the second scenario: aws_db_instance is evaluated correctly.

I've also noticed, that the comment table shows Cost change column. We replaced this column with a breakdown of baseline and usage costs in the latest release, so it's strange to see with infracost/infracost:ci-0.10 image. Could you please double check that it's not cached anyhow? Here's how it should look like now:

[DavidHaasz]

Yeah so the Docker Daemons behind the Bitbucket Runners have caching enabled (not sure on the duration) but will more than likely be the explanation for the above.

I am happy for this issue to be closed.

Thank you very much @vdmgolub for taking the time out to look into and advise on this issue. It is very much appreciated

[vdmgolub]

Hope this resolves it. Thank you for all the provided info 🙏. I'm going to close the issue for now, but please reopen it if this ends up being something different.

Happy Friday to you and have a great weekend! :)