fixes #506 - bot prompts 'What is the question?' when using ElicitResponse #507
Conversation
This file contains 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.
Issue #, if available:
#506
Description of changes:
(1) Modify check for isElicitResponse to provide more robust detection of responsebot enablement using qnabotcontext session attribute. Previous mothod relied on response.result object which was not present during responsebot slot prompting.
(2) Modify lex response to use DialogAction
ElicitIntentinstead ofElicitSlotwhen a responsebot is enabled.The problem reported in #506 is related to the fact that when response bots were active QnABot returned lex reponse
ElicitSlotwithSlotToElicitset toqnaslot, instead of the default intent 'Fullfilled' response. This was done to support Connect integration to avoid the flow leaving the GetCustomerInput block during ElicitResponse interactions.This used to work, possibly because of several factors including (i) the qnaslot slot used to have significantly more sample values (default utterances) that we removed in v5.2.0, since these frequently cause customer confusion are should (in theory) be no longer necessary since adding FALLBACK intent support. (ii) updated models in Lex are stricter in confidence threshold when utterance doesn't resemble a trained slottype value.
By using DialogAction
ElicitIntentinstead, we achieve the same bahavior for Connect integration, but avoid explictly forcing Lex to try to fill the qnaslot, allowing it instead to match the FALLBACK intent on the main bot and allowing the users response to sucessfully pass through to the ELicitResponse bot.I tested it with both Web UI, and with Connect to make sure the chaining demo worked in both cases without problematic prompting.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.