Closed OBrien1510 closed 5 years ago
Please share the code you are using for state. Something like:
Conversation.UpdateContainer(builder =>
{
var memorystore = new InMemoryDataStore();
builder
.RegisterType<InMemoryDataStore>()
.Keyed<IBotDataStore<BotData>>(typeof(ConnectorStore));
builder.Register(c => new CachingBotDataStore(memorystore,
CachingBotDataStoreConsistencyPolicy.ETagBasedConsistency))
.As<IBotDataStore<BotData>>()
.AsSelf()
.SingleInstance();
});
Hi Eric thanks your reply.
This is the current contents of out global.asax.cs file
` namespace NetHope { public class WebApiApplication : System.Web.HttpApplication { CancellationTokenSource _getTokenAsyncCancellation = new CancellationTokenSource();
protected void Application_Start(object sender, EventArgs e)
{
if (ServicePointManager.SecurityProtocol.HasFlag(SecurityProtocolType.Tls12) == false)
{
ServicePointManager.SecurityProtocol = ServicePointManager.SecurityProtocol | SecurityProtocolType.Tls12;
}
//GlobalConfiguration.Configure(WebApiConfig.Register);
var uri = new Uri(ConfigurationManager.AppSettings["DocumentDbUrl"]);
var key = ConfigurationManager.AppSettings["DocumentDbKey"];
var store = new DocumentDbBotDataStore(uri, key);
Conversation.UpdateContainer(
builder =>
{
builder.RegisterModule(new AzureModule(Assembly.GetExecutingAssembly()));
builder.Register(c => store)
.Keyed<IBotDataStore<BotData>>(AzureModule.Key_DataStore)
.AsSelf()
.SingleInstance();
// Register your Web API controllers.
builder.Register(c => store)
.Keyed<IBotDataStore<BotData>>(AzureModule.Key_DataStore)
.AsSelf()
.SingleInstance();
});
this.RegisterBotModules();
GlobalConfiguration.Configure(WebApiConfig.Register);
var appID = ConfigurationManager.AppSettings["MicrosoftAppId"];
var appPassword = ConfigurationManager.AppSettings["MicrosoftAppPassword"];
if (!string.IsNullOrEmpty(appID) && !string.IsNullOrEmpty(appPassword))
{
var credentials = new MicrosoftAppCredentials(appID, appPassword);
Task.Factory.StartNew(async () =>
{
while (!_getTokenAsyncCancellation.IsCancellationRequested)
{
try
{
var token = await credentials.GetTokenAsync().ConfigureAwait(false);
}
catch (MicrosoftAppCredentials.OAuthException ex)
{
Trace.TraceError(ex.ToString());
}
await Task.Delay(TimeSpan.FromMinutes(30), _getTokenAsyncCancellation.Token).ConfigureAwait(false);
}
}).ConfigureAwait(false);
}
}
private void RegisterBotModules()
{
Conversation.UpdateContainer(builder =>
{
builder.RegisterModule(new ReflectionSurrogateModule());
builder.RegisterModule<GlobalMessageHandlersBotModule>();
});
}
protected void Application_End()
{
_getTokenAsyncCancellation.Cancel();
}
}
} ` As far as I know, this code as been taken pretty much verbatim from Microsoft's documentation on the subject
I should also mention that there are items being saved to the database in azure, however how and when the items are saved is quite sporadic and it seems that all the items saved in said database are related solely to the bot framework emulator. We've used it on a skype a few times and there doesn't seem to be anything in that database about a skype client
Please try moving the RegisterBotModules into the Conversation.UpdateContainer above and remove RegisterBotModules. I believe UpdateContainer should only be called once:
Conversation.UpdateContainer(
builder =>
{
builder.RegisterModule(new AzureModule(Assembly.GetExecutingAssembly()));
builder.RegisterModule(new ReflectionSurrogateModule());
builder.RegisterModule<GlobalMessageHandlersBotModule>();
builder.Register(c => store)
.Keyed<IBotDataStore<BotData>>(AzureModule.Key_DataStore)
.AsSelf()
.SingleInstance();
})
Hi Eric,
I'm working with @OBrien1510 and implemented this change this morning. The bot still returns an error, but it does now send a greeting message unlike before where it simply sent out the error message ("Sorry my bot code is having an issue") straightaway. Now it sends the greeting message and then when you try to send a message in response it sends the error message.
We've been dealing with this issue for a while with our two original bots and we had thought that it was to do with CORS. I originally posted about this web chat/direct line issue on Stack Overflow ( https://stackoverflow.com/questions/55260369/ms-bot-framework-v3-web-chat-direct-line-issue-internal-server-error-500?noredirect=1#comment97369555_55260369). This is where we realized that we needed to change our state management. The web chat seemed to be fixed for our original bots when I implemented the changes re the CORS policy and they still worked when I switched the state management to CosmosDB but the new bot (the web app bot as opposed to bot channels registration) still kept returning the same error message (as mentioned above) .
Two days later, however, our original bots stopped working on web chat and direct line so now all three bots behave in the same way on web chat/direct line. Is there something that we are missing? I feel that once one of the bots is fixed, we should be able to fix the others.
The call stack that is returned looks like this for the web bot and channel registrations:
Microsoft.Bot.Schema.BotException:
at Microsoft.Bot.ChannelConnector.BotAPI+
The only difference between the two bot types is when I look at the developer screen on Chrome, with a slight difference between the web bot (first image) and the channels registration bot (second image). I'm not certain how important that difference is but I thought I would include the screenshots just in case.
If there is anything you think that we may not have done correctly or if you need us to send you some of our code please let us know
Can you share the code of the root dialog? (if you cannot share it here, please email me at the address on my profile)
Also, do you have Application Insights configured for the web application? https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net
I will email you on that code now , and yes we do have insights configured.
Closing this, since we are communicating via email and this does not appear to be an SDK or Bot Service issue.
Microsoft Bot SDK v3 (C#)
We have 3 bots, 2 that we've been using for the past few months and one a new one that we needed to create to replace an old one. We pushed the same code to the new bot and it stopped working. Some quick debugging seemed to indicating that the code gets to the moment where the bot should send the activity to root dialog, but then an exception occurs and it never continues. Sometimes it doesn't even make it to that point and it will except somewhere a little earlier. I've tried different versions of the bot connector all the way up to v3.20 (the last stable v3) but not use. As far as I can see, all the settings for the bot are identical to the old bot but I could be possibly missing something . The bot also works as intended locally.
await Conversation.SendAsync(activity, () => new RootDialog());
When testing in webchat, it returns a generic HTTP Internal Server Error.
Please let me know if anymore information is needed
EDIT1:
I found this exception in the application insights
EDIT2:
https://github.com/Microsoft/BotBuilder/issues/4322
Found this post which seemed to be a very similar issue to mine, however changing versions did not appear to work
EDIT3:
Find the full response below
{ "message": "An error has occurred.", "exceptionMessage": "Operation returned an invalid status code 'MethodNotAllowed'", "exceptionType": "Microsoft.Bot.Connector.ErrorResponseException", "stackTrace": " at Microsoft.Bot.Connector.BotState.<GetConversationDataWithHttpMessagesAsync>d__8.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Microsoft.Bot.Connector.BotStateExtensions.<GetConversationDataAsync>d__7.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Microsoft.Bot.Builder.Dialogs.Internals.ConnectorStore.<Microsoft-Bot-Builder-Dialogs-Internals-IBotDataStore<Microsoft-Bot-Connector-BotData>-LoadAsync>d__2.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Microsoft.Bot.Builder.Dialogs.Internals.CachingBotDataStore.<LoadFromInnerAndCache>d__8.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Microsoft.Bot.Builder.Dialogs.Internals.CachingBotDataStore.<Microsoft-Bot-Builder-Dialogs-Internals-IBotDataStore<Microsoft-Bot-Connector-BotData>-LoadAsync>d__6.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Microsoft.Bot.Builder.Dialogs.Internals.BotDataBase
1.EDIT4:
Looking over this post
https://github.com/Microsoft/BotBuilder/issues/4953
The old bot is in East US I believe and the new one is North Europe. Also the old bot is a 'App Service' and a 'Bot Channel Registration' in azure, while the new bot is a 'web app bot'. The resource page for both looks identical but there might be some difference I don't know about. As for the custom state client mentioned in this post. One of my colleagues implemented it recently as we were still using the default and it seemed to be working, at least it is on the original 2 bots
EDIT5: So my colleague hadn't pushed the custom state changes, so I pulled them and then published but the same behaviour outlined above still persists