3

I am new to C# and the Bot Framework (V3) and have been asked to begin testing an existing bot on a project I have joined. The bot itself works fine on the Bot Emulator and when hosted on Skype, but for some reason the web chat on Azure does not work. As the web chat uses the Direct Line, it kind of puts a halt to running tests for now. I have spent a lot of time scouring the V3 Github page and here on SO but I've not been able to find a solution.

The conversation seems to initiate OK to begin, as the Bot sends the user a message but all user responses don't get sent and the Bot responds with the error message 'Sorry, my bot code is having an issue'. See -

Bot error message

Azure lists it as a 500 error - internal server error. see

Error messages in Azure

Error messages in Azure

I then looked at the messages in the Chrome Dev Tools tab and get the same error as well as a 502 error and, more recently (or I never noticed it before), a CORS error as well. See

Chrome Dev Tools console

Chrome Dev Tools console

After this I used Application Insights on Azure and for each instance when I tried to use the Web Chat there would be three items;

  • A customEvent (StatusCode: 200), presumably for the message the Bot sends at the beginning of the conversation.
  • An exception with a problemId "System.Exception at Microsoft.Bot.ChannelConnector.BotAPI+d__31.MoveNext"
  • Another customEvent (StatusCode : 500)

As I'm not very familiar with the whole set-up between C# and the Bot Framework I'm not really sure where the issue lies. Here's some screenshot of what the exception message looks like -

Messages of single operationId

Messages for single operationId

Exception details (1)

Exception details (1)

Exception details (2)

Exception details (2)

Exception details (3)

Exception details (3)

Exception details (4)

Exception details (4)

I had some thoughts on these messages:

  1. The 'Outer assembly' is described as 'Microsoft.Bot.ChannelConnector, Version=3.2.2.5, Culture=neutral, PublicKeyToken=null' - does the lack of a PublicKeyToken mean that the user isn't getting assigned a token because of the error? Or should this be happening first and the error occurring because the user has no token?
  2. The stack trace is pointing at a line in one of the dialog files but from looking at the code, I can't really see what the issue is? I actually removed the section that was being flagged but it simply changed the line in the code where the issue was to the preceding section so I'm not really sure that there is an issue with this file at all?

If anyone has any thoughts on this and what the cause of the issue might be I would really appreciate it.

Additionally, here's two things I've tried to do to fix this that haven't made any difference;

  • Ensured that when publishing the profile to Azure to tick the box to 'Delete all
  • Made sure all packages were up to date (including installing the bot.connector.directline package, which wasn't already there for some reason)
JJIqbal
  • 630
  • 1
  • 8
  • 23
Conor Lawlor
  • 31
  • 5
  • 1
    Are you using a deployment slot for testing? Also, what is the bot using to manage state (table storage, CosmosDb, etc.)? – Steven Kanberg Mar 20 '19 at 19:12
  • Hey, yes we are using a deployment slot for testing. We essentially have two bots -the one I'm working on being the test bot - and each bot is on a deployment slot on a different app service. As for your second question, I think it's using the default settings for state management but I'm not sure what that might be. I do know we use CosmosDB for saving some user conversation data but I don't know if this is the same for state management? Sorry if that's not useful, I will try ask one of the people who originally set up the project to confirm. – Conor Lawlor Mar 21 '19 at 11:22
  • 1
    Ok, thanks for that info. It’s all pieces to the puzzle. New question: I see WebChat errors (including the CORS error) referencing a “testboteurope” resource. However, the Application Insights data references a “TestSlotNetHope” resource. Are you trying to access one resource from the other? – Steven Kanberg Mar 21 '19 at 14:44
  • Ok, as far as I can see, the "TestBotEurope" is our App Service (AS) and then "TestSlotNetHope" is the Bot Channels Registration (BCR), with an associated Applications Insight. I kind of thought that the BCR was part of the AS considering it's all for the same Bot, could that be the case? Considering I'm not all that familiar with the whole project set up (including Azure), this may be an incorrect assumption. – Conor Lawlor Mar 21 '19 at 15:16
  • 1
    Ok, there are a few things I would also suggest you look into. One, check that your bots aren't using State Service for state management. I'm seeing State Store calls to this service, however it was deprecated several months ago. You can read more about State Service and alternative options here: https://blog.botframework.com/2018/04/02/reminder-the-bot-framework-state-service-has-been-retired-what-you-need-to-know/ – Steven Kanberg Mar 24 '19 at 06:49
  • 1
    Also, you mention having the bots in separate deployment slots using different app services. There is a good chance this is the cause of the CORS issue. The host web chat URI should be added as a Trusted Origin in the Direct Line channel for the bot, in question. Navigate to the bot, click the Channels blade and select Direct Line. Scroll to the bottom of that page and, under "Enhanced authentication options", add the URI and click done. – Steven Kanberg Mar 24 '19 at 07:04
  • 1
    Lastly, there were some issues with Direct Line at the North Europe data center. The errors were over several hours and coincide with your bot's connection troubles. – Steven Kanberg Mar 24 '19 at 07:14
  • Hi Steven, thanks so much for those suggestions. The second one (CORS) seems to have worked but I will test on both bots to be sure. I will also look into whether the state management is using the deprecated service and make that change. I will update you in a day or two, but I think that you have solved my problem, so thank you very much for taking the time to help me out. – Conor Lawlor Mar 25 '19 at 10:33

1 Answers1

0

So the resolution to my problem was as per Steven Kanberg's suggestions in the comments above. While our state management had been using the deprecated version (which is now updated), it was a CORS issue caused by the bots being in different deployment slots to the app services. Once the URIs of the app services were added as Trusted Origins the problem was solved. Thanks to Steven Kanberg for all the help.

Conor Lawlor
  • 31
  • 5