# Step Functions Choice Type coerces non-numeric values to 0 for Numeric*Path choices (e.g NumericGreaterThanEqualsPath)

0

Here is a simple state machine to reproduce the bug:

``````{
"StartAt": "First",
"States": {
"First": {
"Type": "Choice",
"Choices": [
{
"Variable": "\$.key",
"NumericGreaterThanEqualsPath": "\$.find",
"Next": "ChoiceMatched"
}
],
"Default": "DefaultChoice"
},
"ChoiceMatched": {
"Type": "Pass",
"Result": "ChoiceMatched",
"End": true
},
"DefaultChoice": {
"Type": "Pass",
"Result": "DefaultChoice",
"End": true
}
}
}
``````

Here are the test cases: // Results in "DefaultChoice" for non-numeric value of key - Expected behavior

``````{
"key": "ABC",
"find": 0
}
``````

// Results in "ChoiceMatched" when "key" is 0 and "find" is non-numeric - Incorrect behavior "ABC" was treated as numeric

``````{
"key": 0,
"find": "ABC"
}
``````

// Results in "ChoiceMatched" when "key" is 1 and "find" is non-numeric - Incorrect behavior was treated as numeric

``````{
"key": 1,
"find": "ABC"
}
``````

// Results in "DefaultChoice" when "key" is -1 and "find" is non-numeric - Incorrect behavior was treated as numeric

``````{
"key": -1,
"find": "ABC"
}
``````

The last three cases show that the "find" attribute's value ("ABC") was converted to numeric and precisely to a value of 0 when comparing against the "key" value of 0. This happens only when non-numeric is a Path variable and not the variable being compared (test case 1). Also, this coersion is only happening for numeric comparisons. Comparisons for other data types such as string etc. work as expected (there is another odd behavior with timestamps but I will ask a different question for that). The documentation for Choice step (https://docs.aws.amazon.com/step-functions/latest/dg/amazon-states-language-choice-state.html) clearly says "For each of these operators, the corresponding value must be of the appropriate type: string, number, Boolean, or timestamp. Step Functions doesn't attempt to match a numeric field to a string value." but this is clearly not the behavior. If this can't be fixed, at least the documentation must be updated to specify any conversion rules. Thanks.