Hi all! I have a questions regarding the max conte...
# help
w
Hi all! I have a questions regarding the max context iterations limit (https://github.com/infracost/infracost/blob/3d1d555e07082add91d6dd27425a9863a626038c/internal/hcl/evaluator.go#L64). Is there a particular reason for this value of 120? If I were to adjust this to say…360, would it create a rift in the universe?
c
Hi Terry, I don’t think there’s a specific reason for 120, but @mysterious-teacher-68276 may have a better idea when he’s back online. Look’s like it’s been increased before so if you want, submit a PR and we’ll see what he says.
w
thank you @crooked-daybreak-55253!
Rather than simply increasing, my thought was to possibly parameterize the max context iterations but I think I need to better understand what this is used for.
c
Yeah that’s not a bad idea. The way the parsing works is that it runs in a loop that expands (e.g.
for_each
) and evaluates blocks until it detects that nothing has changed. So the max is there to prevent it from looping infinitely.
w
ahh, gotcha
Ok that’s good to know I wasn’t sure if it was something performance related
I have a few Terraform projects that have a ton of modules so it runs up against that pretty quick 😆
m
hi @wooden-notebook-80950 as Tim mentioned this variable is to prevent the contextual evaluation loop getting stuck and looping forever. However, in reality you should never really hit this variable. Are you actively seeing your projects hit this threshold? Or are you just inferring that from some other incorrect output. It’s most likely that if you are seeing this threshold hit, we’re hitting some evaluation bug in one or more of your projects which means we get stuck and have unchanged module contexts. So it would be good to share your specific case if you are seeing this and hopefully we can put in a fix. I would not recommend simply “bumping” the number of max context iterations as this will significantly impact performance evaluating projects. It’s much better to understand your specific case and fix the underlying bug there.
w
Thanks @mysterious-teacher-68276, yes my projects are actively hitting this threshold, at least I am assuming so since I’m seeing a number of errors related to hitting the max context iterations like so:
Copy code
module.autoscale_sync_job_records.module.this_autoscale msg="hit max context iterations evaluating module module.autoscale_sync_job_records.module.this_autoscale"
This is followed but a somewhat strange error saying comments can no longer be posted to Github…
Copy code
[2023-08-23T18:20:36.227Z] Error: template: markdown-html.tmpl:80:115: executing "markdown-html.tmpl" at <.PastBreakdown.TotalMonthlyCost>: nil pointer evaluating *output.Breakdown.TotalMonthlyCost
[2023-08-23T18:20:36.328Z] Error posting cost report to Github.
I am assuming its related to hitting the max iterations since comments are posting just fine in projects that do not leverage the same set of modules
As far as the specific use case…I’m running Infracost in CI to generate build time cost analysis comments. The terraform projects pull in a number of TF modules from an npm package we publish which are then placed in the
terraform/modules/
dir before being evaluated by Infracost in conjunction with parent module scripts
m
ok a couple of questions: 1. what version of infracost CLI are you using 2. what is this module:
module.autoscale_sync_job_records.module.this_autoscale
- does it use any 3rd party modules inside it or is it just vanilla terraform? 3. The comment posting might be related, but I don’t think max iterations should affect this
w
1. 0.10.28 2. That module is a submodule of of of the included modules in the project that handles ddb autoscaling policies. So in other words, we have the root module which calls another module which calls
resource_autoscale
in it’s module. 3. 👍
Could Infracost be tripping up on the nested modules perhaps?
m
so
module.autoscale_sync_job_records.module.this_autoscale
doesn’t contain any module calls?
w
nope
er, actually, one sec
ok correction, so from the top…we have a .tf files (dynamodb-autoscaling.tf) which includes a module resource
autoscale_sync_jobs
with a reference to the
dynamodb_table_autoscale_v2
which then includes another reference to the
resource_autoscale
submodule
so 3 layers of modules
Yeah…to your point, bumping the max iterations value did not appear to resolve the issue anyway.
m
the module layering should be fine, it’s likely that there is something within that module that’s causing an infinite contextual loop. Without being able to see the specifics I can’t do much to help. Is there any way you can share the code with us to help debug. We can start a private chat to do this?