You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Module outputs aren't evaluated: for_each over module.<name>.<output> drops the block #116
When C3X parses HCL, an expression that reads a module output (module.<name>.<output>) never resolves. A resource's for_each/count built from one fails, and the block is dropped. An attribute set from one falls back to the catalog default. This happens even when the output is only a literal.
module.db.aws_sqs_queue.q is dropped: WARN for_each evaluation failed; block omitted ... Unsupported attribute: This object does not have an attribute named "queues".
module.db.aws_db_instance.x and aws_db_instance.direct are both priced at the catalog default class, with unresolved_attribute: instance_class could not be evaluated from the configuration.
Terraform resolves all three: the queues are a and b, and the class is db.m7g.large.
Where it seems to come from
In internal/parser/terraform at v0.3.20, buildEvalContext (eval_context.go) sets var, local and data, plus extras (count/each) and resource references (resources.go). Nothing sets module. reservedRoot (resource_refs.go) reserves the name, and json_config.go skips output blocks. It looks like a module's outputs are never evaluated, and never exposed to the module that calls it.
Impact
Our roots get their sizing, queue and bucket lists from a shared, input-free module "cells". With C3X, one Environment's platform root comes to $41/month (Infracost: $535), and its workloads root comes to $0 (Infracost: $252). NAT gateways, ECS services, Lambda, CloudFront, SQS and the RDS class are all lost.
Thanks for the detailed report and the repro, it made this quick to pin down. Fixed in v0.3.21 (#117).
Module outputs are now evaluated, and module.<name>.<output> is in scope for module inputs, locals and resources:
count and for_each built from a module output now expand;
module.x[0].out under count and module.x["key"].out under for_each work;
outputs passed up through nested modules work;
outputs in .tf.json files are read too.
Your repro now resolves db.m7g.large for both instances, and q["a"] and q["b"] are both present.
Upgrade with brew upgrade c3xdev/tap/c3x, or from the release page. If your cells-based roots still show anything off, please reopen with the warning lines and I'll take a look.
Activity
fix(parser): evaluate module outputs (#116) (#117)
andreacappelletti97 commentedon Oct 23, 2026
Thanks for the detailed report and the repro, it made this quick to pin down. Fixed in v0.3.21 (#117).
Module outputs are now evaluated, and
module.<name>.<output>is in scope for module inputs, locals and resources:countandfor_eachbuilt from a module output now expand;module.x[0].outundercountandmodule.x["key"].outunderfor_eachwork;.tf.jsonfiles are read too.Your repro now resolves
db.m7g.largefor both instances, andq["a"]andq["b"]are both present.Upgrade with
brew upgrade c3xdev/tap/c3x, or from the release page. If your cells-based roots still show anything off, please reopen with the warning lines and I'll take a look.