"Repeat this dialog" action does not properly repeat current dialog context when consuming Skill

Describe the bug

“Repeat this dialog”'s expected behavior is re-evaulate the user’s utterance from the Root bot’s recognizer (or at least the dialog in which this action is called), not the skill’s recognizer. Even though the Repeat this dialog action is in the Root bot’s dialog the dialog’s context is still in the Skill, not the root bot.

Version

OS

• macOS
• Windows
• Ubuntu

To Reproduce

Steps to reproduce the behavior:

1. Download Enterprise Assistant template
2. Change recognizer from Orchestrator to Default (LUIS)
3. Call a skill via utterance such as “Who are John’s peers”
4. If “Who are John’s peers” results in multiple results, and user inputs a different utterance without selecting from the multi-prompt, the recognizer’s intent of the user’s new input results in “None”, and the bot doesn’t properly handle the user’s new utterance (the bot only handles utterances in the People skill, so it is properly interrupted if I input an utterance related to the People skill, but not the root bot).

Expected behavior

From the Enterprise Assistant template’s comments, the flow of dialog should be like this :

user : Who are John's peers?
Bot : Here is a list of John's peers : 
user : What's my schedule for tomorrow? (User inputs new utterance without selecting from previous multi-prompt)
Bot : Your schedule for tomorrow is :

Current behavior

user : Who are John's peers?
Bot : Here is a list of John's peers : 
user : What's my schedule for tomorrow? (User inputs new utterance without selecting from previous multi-prompt)
Bot : *LUIS intent recognizer points to None, bot outputs no response. 

Screenshots

User triggers getPeers intent, bot responds with list of peers multi-prompt. User inputs “What are you” (expected behavior is to route this utterance from the root bot’s recognizer so it points to QnAMaker’s chitchat KB) Recognizer’s intent routes to None instead or other intents with very low probability via the skill’s recognizer, NOT root bot’s recognizer.

The expected behavior as per Enterprise Assistant’s comment in ConnectToSkill :

Additional context

Possibly related to this issue over on botbuilder-dotnet : https://github.com/microsoft/botbuilder-dotnet/issues/3930

Possible related issue and resource for minimum reproducible code : https://stackoverflow.com/questions/67541109/bot-framework-how-do-i-stop-a-waterfall-dialog-which-is-waiting-for-a-prompt-re

This might be a feature request if not a bug. I would like an action that cancels all dialogs and routes the user input starting from the beginning as if the user is starting a new conversation. “Manually” triggering a user input if you will. I can get the user’s message from turn.activity.text, all I want is the ability to call an action that stops all dialogs and re-call’s LUIS all the way from the beginning of the stack at the root bot without the user having to manually do it (in order for the user to “manually” do it, they have to repeat the same utterance 2-3 times to exit out of the skill context)

If anyone has any suggestions / workarounds on how to get the behavior I want it would be greatly appreciated.

[johnkm516]

I think I have an answer for this scenario using Custom Actions to update turn.activity after the skill returns. I’ve attached a sample project that includes a custom action called UpdateTurnContextActivity that accepts an activity in and uses it to update what’s in TurnContext. This allows the RepeatDialog action to work as expected after a skill ends.

RepeatDialogWithSkills.zip

You can take the custom action project and add it to your Enterprise Assistant solution, add a project reference in your Root Bot, then update the schema and App Settings > Components config of the Root Bot to use this new action. For more detailed steps, see https://docs.microsoft.com/en-us/composer/how-to-create-custom-actions.

We will not be making any changes in this area to the SDK, but hopefully this will unblock you and allow you to make your own customizations to how things work for your future scenarios.

If you run the attached test bot, you should see the following behavior:

@lauren-mills Thank you for the workaround!

I figured out how to create, package, and run a custom runtime along with my project and put in dozens of trace activities everywhere in the SkillDialog and DialogExtensions to get an idea of how the call stack works. I have a much better understanding of how it works now inside the runtime code and understand why it behaves as it currently does.

I think saving the activity and replacing the activity values as you have done with the custom action is the simplest solution to this issue. The bot can now safely be interrupted from within the skill context, and route to unknown intent or other skills as needed.

Thank you so much for your explanations. I definitely learned a lot about how the SDK itself works from exploring this issue. I think this issue can be closed.

[lauren-mills]

I think I have an answer for this scenario using Custom Actions to update turn.activity after the skill returns. I’ve attached a sample project that includes a custom action called UpdateTurnContextActivity that accepts an activity in and uses it to update what’s in TurnContext. This allows the RepeatDialog action to work as expected after a skill ends.

RepeatDialogWithSkills.zip

You can take the custom action project and add it to your Enterprise Assistant solution, add a project reference in your Root Bot, then update the schema and App Settings > Components config of the Root Bot to use this new action. For more detailed steps, see https://docs.microsoft.com/en-us/composer/how-to-create-custom-actions.

We will not be making any changes in this area to the SDK, but hopefully this will unblock you and allow you to make your own customizations to how things work for your future scenarios.

If you run the attached test bot, you should see the following behavior: