Repository navigation
fix: report out-of-bounds Fn::Select on a literal list - #4695
Merged
Merged
Conversation
An Fn::Select with a hardcoded index greater than or equal to the length of a hardcoded list passed linting silently, then failed at deploy time with "Fn::Select cannot select nonexistent value at index N". Detect this definite error in the E1017 rule so it is reported regardless of the target property's schema constraints. Fixes aws-cloudformation#4693
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4695 +/- ##
=======================================
Coverage 94.64% 94.65%
=======================================
Files 434 434
Lines 15543 15558 +15
Branches 3015 3018 +3
=======================================
+ Hits 14711 14726 +15
Misses 454 454
Partials 378 378
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:
|
Replace the imperative out-of-bounds check with a per-instance schema. When the list is hardcoded its length is fixed, so inject a "maximum" of len-1 alongside the existing "minimum": 0 and let the standard keyword validators report the out-of-bounds index with their standard message (e.g. "5 is greater than the maximum of 1").
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4693
Fn::Selectwith a hardcoded index that is greater than or equal to the length of a hardcoded list passed linting with 0 errors, then failed at deploy time:Root cause
select()in_resolvers_cfn.pysimplycontinues when the index is out of bounds, yielding nothing. Even if it emitted a resolution error,BaseFn.resolve()short-circuits when the target property's schema has no constraining keywords (_has_schema_constraints), so an out-of-bounds!Selectin an unconstrained context (e.g. anOutputsvalue) would still pass silently.Fix
Detect the out-of-bounds case directly in the
E1017rule (Select.py). The length of a literal list is fixed at authoring time — functions used as list items still each count as one element — so a hardcoded, non-negative integer index>= len(list)is always a definite deploy-time failure. Because the check lives in the rule (not the resolver), it fires regardless of the target property's schema.Only fires when both the index is a hardcoded non-negative integer and the list is a hardcoded array; a
Ref/function index or a function-produced list is left alone (it can resolve to anything at deploy time).Tests
!Select [1, ["bar"]]produced no error.