Bot routing is only working on alternate turns

[yashpungaliya]

Describe the bug

1. I am following the bot routing steps: https://github.com/aws-solutions/aws-qnabot/blob/main/BotRoutingREADME.md, however, it only gets routed to the Lex bot exactly every alternate turn.
2. If I want to support 2 locales, I would create 2 Lex v1 bots, however, in the admin console since I can only enter questions in English, how do I route to the correct locale bot since I would only have a common question in English. Currently, if I configure a QnA in English, enter the german form in the client, the question gets routed to the bot setup for DE, however the response still shows up in English (translated form of what I have given in the Lex bot in german)

To Reproduce

1. Setup a Lex v1 bot
2. Configure a QnA with bot alias, version, name in Advanced section.
3. Try querying using client 2 times.
4. The first request gives the default answer (checking...) configured in the QnA admin page, the second request routes to the Lex use-case bot. I have configured to return params on Lex fulfilment, so the params are returned every alternate turn.

{
      "qid": "BotRoutingTest",
      "a": "checking...",
      "botRouting": {
        "specialty_bot": "OrderBot_versionOne",
        "specialty_bot_name": "OrderBot_versionOne",
        "specialty_bot_alias": "aliasVersionOne"
      },
      "type": "qna",
      "q": [
        "Where is my order?"
      ]
    }

Expected behavior The request should route to the Lex use-case bot.

Please complete the following information about the solution:

• (SO0189) QnABot with admin and client websites - (Master v5.0.0)
• [ eu-west-1]
• [ No] Was the solution modified from the version published on this repository?
• [ NA] If the answer to the previous question was yes, are the changes available on GitHub?
• [ No] Have you checked your service quotas for the sevices this solution uses?
• [ No] Were there any errors in the CloudWatch Logs?

Screenshots NA

Additional context Compared the logs coming to the fulfillment lambda in Cloudwatch, these params only are visible for the request where it is routed to specialty bot and not for the others.

sessionState.sessionAttributes.qnacontext

"specialtyBot\":\"OrderBot_versionOne\",\"specialtyBotName\":\"OrderBot_versionOne\",\"specialtyBotAlias\":\"aliasVersionOne\"}"

[yashpungaliya]

From what I understood looking at 3, this is happening because ES is called after specialtyBot is called. I would expect ES to be queried first so that the specialty bot config can be picked up.

I was able to get it working after adding another call to specialtBot here and would need something similar to elicit bot too.

[bobpskier]

@yashpungaliya The initial question only enables bot routing for subsequent input to qnabot. The answer to this initial question is provided as the response and the session attributes are set to indicate subsequent routing to the target bot. Further input to qnabout is then routed to the target bot until use of the specialty bot is terminated either through user input or by the specialty bot.

User	QnABot	Specialty Bot
I'd like to log food nutrition	Great, what did you eat?
I had a steak and fries	(routed)	You just consumed 1193 Calories
I had a milk shake	(routed)	You just consumed 541 calories
No more food	Ok thanks. You are back to QnABot

From what I can see in your question this is what you are seeing. The input which enables routing is not passed to the specialty bot. Just the subsequent conversation and response is passed to the specialty bot.

Sometimes its good to configure a ResponseCard with buttons on the initial question to help guide the user on what could be entered next.

Let me know if this answers your question or if you'd like to see a different use case for bot routing.

[yashpungaliya]

Hi @bobpskier, but wouldn't we want to directly route to the Specialty Bot sometimes in the 1st request itself? For example, user wants to enquire about food nutrition and asks QnABot: 'I'd like to log food nutrition for a milkshake', in that case, we woudn't want to ask the user Great, what did you eat? which is provided statically in the admin console, rather allow the SpecialtyBot to determine whether the slot has already been provided or not

[bobpskier]

Sometimes you might want to route to the specialty bot on the first invocation and sometimes you might not want to route on the first invocation and instead provide hints about how to use the specialty bot. The current implementation will not pass the invocation utterance on to the specialty bot.

One approach to change this behavior is to implement a lambda hook attached to the qid which starts future routing. This lambda hook could invoke the target bot and set response session attributes as needed. Hence when the question is first used, the normal processing would setup further routing and the lambda hook could look at this routing and make the first invocation to the target bot via either lexv1, lexv2, or lambda call. It would be similar to the code in lambda/fulfillment/lib/middleware/specialtyBotRouter.js. You'd have to pull this into a new lambda function, resolve the external dependencies, pull out the res, req, botName, and botAlias arguments to use in a new top level handler function. The logging calls would need to be changed to use only console.log. Using this approach I believe its possible to implement this mechanism.

[yashpungaliya]

I believe there would be use-cases where they would expect QnA bot to handle invocation in first turn itself, instead of letting specialty use-cases add an additional lambda hook, we can query specialty bot from here directly. I made some changes to the file and got it working for both the cases.

[fhoueto-amz]

hi We are looking into this and will update you fabien

[marcburnie]

@yashpungaliya - we're providing bot routing enhancements provided by @bobpskier PR: https://github.com/aws-solutions/qnabot-on-aws/pull/575. These changes will be made publicly available during the next minor release (in a few months). The changes include passing an initial utterance to the specialty bot, which should resolve this issue. Please let me know if there are any remaining issues/observations; reading through this history it sounds like you've already found a workaround.

[marcburnie]

This issue has been resolved in v5.5.0.