Unusual behaviour of invalid slot input

[dangollayan]

Describe the Issue: We are encountering intermittent responses when inputting invalid values into a slot. Occasionally, the response originates from the ELICIT_RESPONSE_RETRY_MESSAGE, while at other times, it stems directly from the slot message within the bot.

Please refer to this sample:

Steps to Reproduce:

1. Initially, a custom responseBot was created. You can refer to this extracted bot JSON QNAName_Bot-DRAFT-JYGSKBYNQI-LexJson(1).zip

2. The content of this responseBot solely comprises the sample utterance and a slot with the type AMAZON.FirstName.

3. Integration was established with a question from the QnA Bot Designer.

Expected behavior: N/A

Please complete the following information about the solution:

• [Version v5.5.0 ] Version
• [ Sydney] Region:
• [no] Was the solution modified from the version published on this repository?
• [ x] If the answer to the previous question was yes, are the changes available on GitHub?
• [yes] Have you checked your service quotas for the services this solution uses?
• [no] Were there any errors in the CloudWatch Logs?

[dougtoppin]

@dangollayan Thank you for your report. We will investigate and get back to you.

[fhoueto-amz]

Hi @dangollayan This is the expected behavior. Please to https://docs.aws.amazon.com/lexv2/latest/dg/built-in-intent-fallback.html. As stated "Amazon Lex V2 matches the fallback intent in these situations:

The user's input to an intent doesn't match the input that the bot expects

Audio input is noise, or text input isn't recognized as words.

The user's input is ambiguous and Amazon Lex V2 can't determine which intent to invoke."

So when your input is not recognized as words, the main bot Fallback is invoked right away. When your input is recognized as words, the qna main bot intent is invoked which passes the input to your elicit bot which then tries to match the name and will fall back if not recognizing a name. So the intent match is what is playing out here. Even with the same input, as previous context of the conversation are passed through the intent match may vary i.e. the same intent can match a slot in a given context but not in another context.