Align for_each collection validation with its documented key semantics
Nobody has claimed this yet.
- #88 by @lonegunmanb — closed without merging
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 52/100
Research direction
Start with BaseConfig.expandBlock in base_config.go at the linked lines and trace how for_each values are validated and converted to instance keys. The issue leaves open whether to enforce Terraform-compatible types or document broader iterable support, so settle that contract before changing validation. Add table-driven tests for the listed collection types; done means validation, diagnostics, addresses, and tests agree with the chosen semantics.
Written by the indexing model from the issue text.
Description
Summary
BaseConfig.expandBlock reports that for_each accepts a set or map, but its validation accepts every cty value for which CanIterateElements() is true. Lists, tuples, objects, and sets with non-string elements are therefore accepted with semantics that are broader than the diagnostic and Terraform-style for_each behavior.
Observed on main at commit 1d1c394b55ea36a8dc98495850430e4da643b1eb.
Reproduction
All of these currently reach expansion:
example "item" {
for_each = ["a", "b"]
}
example "number" {
for_each = toset([1, 2])
}
example "empty" {
for_each = []
}
The validation is only:
if !forEachValue.CanIterateElements() {
return nil, fmt.Errorf("invalid `for_each`, except set or map: %s", attr.Range().String())
}
Actual behavior
Values outside the stated set/map contract are expanded. Sequence indices and arbitrary cty keys become instance keys through CtyValueToString, making address stability depend on undocumented behavior.
Expected behavior
The accepted type family and key semantics should be explicit and consistent across validation, diagnostics, addresses, and tests.
For Terraform-compatible behavior, accept maps/objects and sets of strings, and reject lists, tuples, and non-string sets. If Golden intentionally supports all iterable values, update the error and document stable key/address semantics for each supported family.
Suggested direction
Centralize for_each type validation before iteration and add table-driven tests for map, object, set(string), list, tuple, empty collections, and non-string sets.
- Dominant language
- Go
- Stars
- 3
- Forks
- 13
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/golden
-
blockToCtyValue ignores Valuable.Values() and may panic during reflectionMay be free again A pull request for this issue was closed without being merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
VariableBlock panics when planning object-typed variablesMay be free again A pull request for this issue was closed without being merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
locals can be paired with the wrong preserved expression due to independent map iterationPossibly taken @lonegunmanb claimed this 86 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 72/100
-
VariableBlock rejects optional object attribute defaultsMay be free again A pull request for this issue was closed without being merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 68/100
-
Top-level for_each instances share mutable HCL AST and corrupt nested block valuesMay be free again A pull request for this issue was closed without being merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 55/100
Similar issues
-
VLAgent `spec.k8sCollector.includePodLabels: false` has no effectPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
VictoriaMetrics/operator#2772 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Gaurav-Gosain/tuios#1316 ·
Maintainers usually reply within 1 day
-
needs: investigation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
area:auth documentation priority:low
Difficulty 1/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
Mend: dependency security vulnerability
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
kube-tarian/sigrun#203 ·