Repository navigation
Conversation
|
Hi maintainers, the CI workflow run for this PR is waiting on first-time-contributor approval. Could someone approve the run when you get a chance? Thanks! |
OKAN-SOFTWARE
left a comment
There was a problem hiding this comment.
Validated commit a6bc768 locally using Python 3.12.14.
- All 338 function and condition tests passed, including the 23 FindInMap tests.
- Nine full-template checks through
cfnlint.api.lintpassed. - Replacing the implementation with current main produced 3 failures and 20 passes in the focused suite, confirming the new error-detection coverage.
Confirmed that missing lookup keys are reported in condition operands, Fn::Join items, Fn::Sub variables, and Lambda environment variables. The constrained-property control still reports exactly one error.
Valid lookups and DefaultValue fallbacks—including a missing map with a fallback—remain accepted. Failures originating from an overridable parameter Default remain suppressed.
No blocking issue found within the reviewed scope. Validation was local; no AWS deployment was performed.
|
Thanks for validating this locally, including the focused-suite comparison against main and the constrained-property control. No action on my side from this review; the PR still awaits maintainer review and the first-time-contributor CI approval. |
a6bc768 to
7bd5682
Compare
|
Rebased onto current main: the branch had gone dirty after #4810 merged. The only conflict was in test_find_in_map.py, where #4810 added the map-name-from-parameter-Default cases to the same test region. Resolution keeps both sets intact: #4810's cases stay with test_resolve_map_name_from_parameter_default, and this PR's cases stay with test_resolve_without_schema_constraints. Verified locally: 30/30 in test_find_in_map.py and 306 passed across test/unit/rules/functions/, ruff clean. |
|
Thanks for rebasing and preserving both regression test groups. |
A literal Fn::FindInMap whose map name or keys are not in Mappings was reported only where the surrounding schema constrains the value. In a Condition operand, an Fn::Join item, an Fn::Sub variable, or an unconstrained property no rule reported it, even though CloudFormation rejects the template at ValidateTemplate. The cause is the early return in BaseFn.resolve when the target schema carries no constraining keyword: the map and key check runs only during that resolution. Override resolve in FindInMap so resolution still runs for its errors when there are no schema constraints, while value validation still only runs when constraints exist. The per-position rule attribution is unchanged, so the same templates now report E8003, E1022, E1019, and E1011 respectively, matching the pre-1.47.0 behavior. Fixes aws-cloudformation#4873 Signed-off-by: Varshith Puli <pulivarshit@gmail.com>
7bd5682 to
b43b7a0
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4919 +/- ##
=======================================
Coverage 94.75% 94.75%
=======================================
Files 442 442
Lines 16105 16120 +15
Branches 3125 3130 +5
=======================================
+ Hits 15260 15275 +15
Misses 466 466
Partials 379 379
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Fixes #4873
Problem
A literal
Fn::FindInMapwhose map name or keys are not inMappingswas reported only where the surrounding schema constrains the value. In a Condition operand, anFn::Joinitem, anFn::Subvariable, or an unconstrained property, no rule reported it, even though CloudFormation rejects the template atValidateTemplatewithTemplate error: Unable to get mapping for ....The cause is the early return in
BaseFn.resolvewhen the target schema carries no constraining keyword: the map and key check runs only during that resolution.Fix
Override
resolveinFindInMapso resolution still runs for its errors when there are no schema constraints, while value validation still only runs when constraints exist. The per-position rule attribution is unchanged, so the issue's templates now report exactly as 1.46.0 did: E8003 in a Condition operand, E1022 in anFn::Joinitem, E1019 in anFn::Subvariable, and E1011 in a constrained property.Deliberately not changed:
DefaultValuestill do not report a bad key, since the lookup cannot fail at deploy time.Defaultstill do not report, since a deployer can override them (same rule as the constrained path).Verification
Reproduced all four issue positions on current main first (no output, exit code 0, except the control). After the fix, each reports its rule at the lookup, and the constrained control still reports E1011 with no duplicates.
Test results (run against the branch source):
test/unit/rules/functions/test_find_in_map.py: 23 passed (6 new unconstrained-path cases)test/unit/rules/functions/andtest/unit/rules/conditions/: 338 passedtest/unit/rules/: 2086 passedtest/unit/module/: 1022 passed, 9 failed. The 9 failures are pre-existing on unmodified main (CLI arg listing, pricing specs, graph tests) and are unrelated to this change.ruff checkandruff format --checkclean on all touched files.