Virtual Assistant
Typescript
Below code is not been called on errors. This can be found in defaultAdapter.ts
this.onTurnError = async (context: TurnContext, error: Error): Promise<void> => {
console.log('defaultAdapter.onTurnError: ===>', error);
await context.sendActivity({
type: ActivityTypes.Trace,
text: error.message
});
await context.sendActivity({
type: ActivityTypes.Trace,
text: error.stack
});
await context.sendActivity(i18next.t('main.error'));
telemetryClient.trackException({ exception: error });
};
Create a Virtual Assistant and throw an explicit error.
This should be called on errors which are not been handled. For example, if there is a path issue, or LUISservice or QnA Service not found etc..
No.
Hi @SreekanthOAuth, we are validating some scenarios to check that behavior you mentioned. We will get back to you later.
Hi @SreekanthOAuth, we managed to reproduce the scenario that you mentioned.
We identified that the onTurnError event is not executed when the ShowTypingMiddleware is enabled in the DefaultAdapter. As a workaround you can remove that middleware.
Hope this helps you 😊. We will be checking the differences of the ShowTypingMiddleware's implementation and we will get back to you later.
_ShowTypingMiddleware disabled in DefaultAdapter_

_OnTurnError() event executed when an error raised_

After commenting, this is been called. But the conversation is not ending. Can you please check this as well.
Thanks,
Sreekanth
We identified the following related issues of botbuilder-js repository explaining the reason that the ShowTypingMiddleware is not propagating the error to the adapter that fires the onTurnError handler function.
• microsoft/botbuilder-js#726 - ShowTypingMiddleware suppresses errors and does not allow adapter.onTurnError to handle them
• microsoft/botbuilder-js#1170 -ShowTypingMiddleware provoke silent error behaviour
@darrenj - as this issue is related to the implementation of the ShowTypingMiddleware of botbuilder-js. Should we transfer the issue to the botbuilder-js repository?
@SreekanthOAuth - we couldn't reproduce the scenario that the dialog is not ending, so I need you to give me a full overview of what you're doing in order to figure out what's wrong.
@Batta32 , thanks for the info.
In our case, we have custom skills. So, when the intent goes to skill from VA if any error occurred in skill, getting the error from OnTurnError (from skill level) to the user. But it's not coming back to VA. In this case, if we request the different utterance, it starts directly from there in skill, not from VA.
So meaning, the conversation is not getting ended.
Yes followed the same repo to create the VA.
And followed below link to create a custom skill
custom skill
We identified the following related issues of botbuilder-js repository explaining the reason that the
ShowTypingMiddlewareis not propagating the error to the adapter that fires theonTurnErrorhandler function.
• microsoft/botbuilder-js#726 - ShowTypingMiddleware suppresses errors and does not allow adapter.onTurnError to handle them
• microsoft/botbuilder-js#1170 -ShowTypingMiddleware provoke silent error behaviour@darrenj - as this issue is related to the implementation of the ShowTypingMiddleware of
botbuilder-js. Should we transfer the issue to the botbuilder-js repository?@SreekanthOAuth - we couldn't reproduce the scenario that the dialog is not ending, so I need you to give me a full overview of what you're doing in order to figure out what's wrong.
- Can you share the entire repro steps?
- Are you using the sample-assistant of _master_ branch?
Thanks - I've raised with the botbuilder JS team as I don't think ithis is by design. Will report back, we should keep the issue here and take a look at the end of conversation aspect.
Hi @SreekanthOAuth, we managed to reproduce the scenario of the end of conversation.
We noticed that the conversation is not ending when an error is raised in the Skill's side, in C# and in TypeScript as well. We are analyzing some alternatives and we will get back to you later 😊.
Also, we noticed that this scenario is happening regardless the showTypingMiddleware is commented or not. Can you verify this?
Martin,
Yes, This scenario is happening regardless of showTypingMiddleware is
commented or not.
Thanks,
Amit Mistry
On Thu, Dec 5, 2019 at 7:40 PM Martin Battaglino notifications@github.com
wrote:
Hi @SreekanthOAuth https://github.com/SreekanthOAuth, we managed to
reproduce the scenario of the end of conversation.We noticed that the conversation is not ending when an error is raised
in the Skill's side, in C# and in TypeScript as well. We are analyzing some
alternatives and we will get back to you later 😊.Also, we noticed that this scenario is happening regardless the
showTypingMiddleware is commented or not. Can you verify this?—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/botframework-solutions/issues/2766?email_source=notifications&email_token=AA5PTC645DPL4W6MXF7B5WTQXEDU7A5CNFSM4JSRXNUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGA2KOA#issuecomment-562144568,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA5PTCZTAEQOZ5KKCEYZFZLQXEDU7ANCNFSM4JSRXNUA
.
Hi @SreekanthOAuth, @amistry79, we created the Pull Request #2800 which solves the end of conversation aspect!
As the MainDialog of the Skill extends to RouterDialog, we should manage the onContinueDialog event in order to handle the errors and finish the executed dialog without saving the last conversation's state.
Also, we identified the issue #1589 (OnTurnError function inside DefaultAdapter doesn't end the current dialog) which is similar and contains a workaround for your scenario.
To accomplish this, you should create a base dialog, in your solution, to be inherited directly from the MainDialog of your Skill and manage the onContinueDialog event ending the executed dialog.
See this example.
Hope this helps you 😊.
Most helpful comment
Thanks - I've raised with the botbuilder JS team as I don't think ithis is by design. Will report back, we should keep the issue here and take a look at the end of conversation aspect.