1

I send a message using PromptCustomDialog. If a person cannot answer a question for some time, how can the next message be sent? I would be grateful for the examples.

await context.Forward(new PromptCustomDialog(message, answers), Complete, context.MakeMessage(), CancellationToken.None);

public async Task Complete(IDialogContext context, IAwaitable<string> result)
   {
        var res = await result;
        string response = res;
        await Choose(context, response);
    }
Drew Marsh
  • 33,111
  • 3
  • 82
  • 100
M.Tony
  • 11
  • 2
  • Welcome to Stack Overflow. Can you explain a little more about what you're trying to accomplish? Are you saying you want the bot to send a message and then if the user doesn't respond in, say, 30 seconds you want the bot to send a followup message? Would it be like "Hi, what's your name?" and then "I haven't received anything from you. Are you still there?" – Kyle Delaney Jan 11 '19 at 01:19
  • @KyleDelaney you very accurately described what I need. – M.Tony Jan 12 '19 at 17:07
  • Is Drew's answer acceptable? – Kyle Delaney Jan 13 '19 at 06:05
  • @KyleDelaney It does not describe how to do this for a message with buttons(await context.Forward(new PromptCustomDialog(message, answers), Complete, context.MakeMessage(), CancellationToken.None);) Problem with multiple resume handlers. – M.Tony Jan 13 '19 at 08:01
  • Then you need to put more information in your question. You didn't say anything about buttons and we don't know what `PromptCustomDialog` is. It would help if you shared more relevant code. – Kyle Delaney Jan 15 '19 at 01:07
  • Are you still working on this? – Kyle Delaney Jan 21 '19 at 23:32

1 Answers1

1

This would require you to set some kind of timer that would trigger an event that would cause the bot to send out a proactive message to the user. You can read more about sending proactive messages here.

The only thing I would point out is that bots, like web services, are often running multiple instances across multiple servers (e.g. if you're deployed on Azure App Services), so you would need to use some kind of distributed, stateful timer service to help you with this to ensure that the timer fires and triggers the event no matter what server it originated from.

Drew Marsh
  • 33,111
  • 3
  • 82
  • 100
  • Hi Drew, I'd be interested in more information about this. What could prevent the timer from firing and sending the message if it's just running on the same server that received the message from the user? – Kyle Delaney Jan 13 '19 at 06:09
  • Hi Kyle! What I mean is that, if your bot is scaled across multiple servers, which it _should be_ to provide fault tolerance, there's no (good) way to guarantee which server your user's activities are being sent to at any given time. So if your bot's logic creates a timer that represented by only local (in-memory on local disk) state, then you'll have a problem scaling your solution out. Beyond that, even if you had just a single server, you need to account for the server being restarted, the process crashing, etc. – Drew Marsh Jan 13 '19 at 16:48
  • Okay, I'm guessing the problem is that you'd have no way to stop a local timer, which you'd need to do when the user sends a message. If the timer didn't need to be stopped then I still don't understand why it would be a problem to just let the timer run using local state on whichever server received the activity. – Kyle Delaney Jan 15 '19 at 00:57
  • @KyleDelaney what if the process crashes? what if the server is rebooted? what if your service gets scaled down or migrated to new servers (Cloud)? other considerations are scaling the number of actual timers that are running. typically a scalable service would maintain a list of times and have a small pool of worker timers processing them. there are many reasons why it doesn't work unless you don't have to worry about these concerns for your target scale. – Drew Marsh Jan 15 '19 at 02:07
  • Couldn't the timer process could crash no matter what server it's on? Couldn't whatever server the timer is on be rebooted? – Kyle Delaney Jan 15 '19 at 04:14
  • 1
    Yes, you would want the timer itself to be maintained by some kind of persistent, distributed solution. IMHO baking all of that into your bot directly would violate all sorts of architectural patterns (SRP to begin with), not to mention you'd be reinventing the wheel on something that is not as simple to build as one might think. If it works for your situation, by all means go for it... no need to overengineer if it's not a requirement. I just want to make sure to call it out so people are aware of the potential pitfalls. Cheers! – Drew Marsh Jan 15 '19 at 04:39