0
votes

We have a local (not azure) deployment of a bot using MS bot framework. Currently the service is running on three machines, all serving the single api endpoint. Everything works fine when we only have the service running on one machine. If we run it on all three, however, the conversation context can get lost. For example, here is a flow we have:

  1. User says they want to do x
  2. Bot matches with the correct LUIS intent, and asks for more information
  3. User provides necessary info (an IP address)
  4. Bot runs a method to find the info they want and returns it to them. We do this by context.Wait().

If we have the service running on multiple machines, this is what happens sometimes:

  1. machine A handles step 1 and 2
  2. the controller on machine B gets the answer the user provides in step 3 and, I assume because it doesn't have the conversation context machine A had, it sends that text to LUIS rather than calling the method that should be called. LUIS doesn't have an intent that matches the IP, and an error occurs.

What's the best way to handle maintaining conversation context when the service is running on multiple machines? Context.Forward? And/or other ideas?

Thanks!

2
Could you include part of code you are talking about? It looks you could have problem in custom behavior of your application.Ferdinand Fejskid
What are you using for bot state? Are you using the Azure Extensions github.com/Microsoft/BotBuilder-Azure ?Eric Dahlvang

2 Answers

0
votes

A bit of a strange question. The way LUIS runs is it initially checks for Intent and then finds out relevant entities for the intent, thus resulting a prediction for us to provide a response. Whatever the service you run in your localhost, you have to keep in mind that the key language processor runs in azure cloud.The SDK's are just implementations. Such that it can easify the communication in between the chat interface (In your case would be bot emulator) and the LUIS app service (MS Cognitive Services). I'm still unclear about this architecture that you are mentioning about though.

0
votes

The solution to this turned out to be use a non-memory state store. Thanks to Eric Dahlvang for pointing that out. I thought that was it, but then thought it must not be because it sometimes worked with multiple machines handling a conversation and sometimes didn't with the in memory state store. Still not clear on why it worked sometimes and not others. (As mentioned, one complication was that I cannot debug in the environment in which the behavior manifested, hence I was relying on logging to see what was happening. It's possible that the logging I was looking at was misleading. I can't think of how it could have been misleading, but it is possible and that is one possible explanation.)