Skip to content

fix(E1011): report bad Fn::FindInMap keys in unconstrained positions - #4919

Merged
kddejong merged 1 commit into
aws-cloudformation:mainfrom
Varshith-Kali:fix-4873-findinmap-unconstrained
Nov 2, 2026
Merged

kddejong merged 1 commit into
aws-cloudformation:mainfrom
Varshith-Kali:fix-4873-findinmap-unconstrained

Conversation

@Varshith-Kali

Copy link
Copy Markdown
Contributor

Fixes #4873

Problem

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 with Template error: Unable to get mapping for ....

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.

Fix

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 issue's templates now report exactly as 1.46.0 did: E8003 in a Condition operand, E1022 in an Fn::Join item, E1019 in an Fn::Sub variable, and E1011 in a constrained property.

Deliberately not changed:

  • Lookups with a DefaultValue still do not report a bad key, since the lookup cannot fail at deploy time.
  • Keys resolved from a parameter Default still do not report, since a deployer can override them (same rule as the constrained path).
  • Unconstrained positions gain no new resolved-value findings, only definite lookup failures.

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/ and test/unit/rules/conditions/: 338 passed
  • test/unit/rules/: 2086 passed
  • test/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 check and ruff format --check clean on all touched files.

@Varshith-Kali

Copy link
Copy Markdown
Contributor Author

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 OKAN-SOFTWARE left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.lint passed.
  • 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.

@Varshith-Kali

Copy link
Copy Markdown
Contributor Author

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.

@Varshith-Kali
Varshith-Kali force-pushed the fix-4873-findinmap-unconstrained branch from a6bc768 to 7bd5682 Compare October 31, 2026 01:01
@Varshith-Kali

Copy link
Copy Markdown
Contributor Author

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.

@OKAN-SOFTWARE

Copy link
Copy Markdown

Thanks for rebasing and preserving both regression test groups.
The updated diff looks consistent with my earlier review. No further concerns from my side.

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>
@kddejong
kddejong force-pushed the fix-4873-findinmap-unconstrained branch from 7bd5682 to b43b7a0 Compare November 2, 2026 17:45
@codecov

codecov Bot commented Nov 2, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.75%. Comparing base (4c7581a) to head (b43b7a0).

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           
Flag Coverage Δ
unittests 94.75% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

3 participants