We Keep Coding

Leaving custom prompt validation in Bot Framework V4

I started building a dialog in Microsoft's Bot Framework V4 and for that I want to use the custom validation of prompts. A couple of month ago, when version 4.4 was released, a new property "AttemptCount" was added to the PromptValidatorContext. This property gives information on how many times a user gave an answer. Obviously, it would be nice to end the current dialog if a user was reprompted several times. However, I did not find a way to get out of this state, because the given PromptValidatorContext does not offer a way to replace the dialog, unlike a DialogContext (or WaterfallStepContext). I asked that question on github, but didn't get an answer.
public class MyComponentDialog : ComponentDialog
{
readonly WaterfallDialog waterfallDialog;
public MyComponentDialog(string dialogId) : (dialogId)
{
// Waterfall dialog will be started when MyComponentDialog is called.
this.InitialDialogId = DialogId.MainDialog;
this.waterfallDialog = new WaterfallDialog(DialogId.MainDialog, new WaterfallStep[] { this.StepOneAsync, this.StepTwoAsync});
this.AddDialog(this.waterfallDialog);
this.AddDialog(new TextPrompt(DialogId.TextPrompt, CustomTextValidatorAsync));
}
public async Task<DialogTurnResult> StepOneAsync(WaterfallStepContext stepContext, CancellationToken cancellationToken)
{
var promptOptions = new PromptOptions
{
Prompt = MessageFactory.Text("Hello from text prompt"),
RetryPrompt = MessageFactory.Text("Hello from retry prompt")
};
return await stepContext.PromptAsync(DialogId.TextPrompt, promptOptions, cancellationToken).ConfigureAwait(false);
}
public async Task<DialogTurnResult> StepTwoAsync(WaterfallStepContext stepContext, CancellationToken cancellationToken)
{
// Handle validated result...
}
// Critical part:
public async Task<bool> CustomTextValidatorAsync(PromptValidatorContext<string> promptContext, CancellationToken cancellationToken)
{
if (promptContext.AttemptCount > 3)
{
// How do I get out of here? :-/
}
if (promptContext.Context.Activity.Text.Equals("password")
{
// valid user input
return true;
}
// invalid user input
return false;
}
}
If this feature is actually missing, I could probably do a workaround by saving the information in the TurnState and checking it in my StepTwo. Something like this:
promptContext.Context.TurnState["validation"] = ValidationEnum.TooManyAttempts;
But this doesn't really feel right ;-)
Does anyone has an idea?
Cheers,
Andreas

You have a few options depending on what you want to do in the validator function and where you want to put the code that manages the dialog stack.
Option 1: return false
Your first opportunity to pop dialogs off the stack will be in the validator function itself, like I mentioned in the comments.
if (promptContext.AttemptCount > 3)
{
var dc = await BotUtil.Dialogs.CreateContextAsync(promptContext.Context, cancellationToken);
await dc.CancelAllDialogsAsync(cancellationToken);
return false;
}
You were right to be apprehensive about this, because this actually can cause problems if you don't do it correctly. The SDK does not expect you to manipulate the dialog stack within a validator function, and so you need to be aware of what happens when the validator function returns and act accordingly.
Option 1.1: send an activity
You can see in the source code that a prompt will try to reprompt without checking to see if the prompt is still on the dialog stack:
if (!dc.Context.Responded)
{
await OnPromptAsync(dc.Context, state, options, true, cancellationToken).ConfigureAwait(false);
}
This means that even if you clear the dialog stack inside your validator function, the prompt will still try to reprompt after that when you return false. We don't want that to happen because the dialog has already been cancelled, and if the bot asks a question that it won't be accepting answers to then that will look bad and confuse the user. However, this source code does provide a hint about how to avoid reprompting. It will only reprompt if TurnContext.Responded is false. You can set it to true by sending an activity.
Option 1.1.1: send a message activity
It makes sense to let the user know that they've used up all their attempts, and if you send the user such a message in your validator function then you won't have to worry about any unwanted automatic reprompts:
await promptContext.Context.SendActivityAsync("Cancelling all dialogs...");
Option 1.1.2: send an event activity
If you don't want to display an actual message to the user, you can send an invisible event activity that won't get rendered in the conversation. This will still set TurnContext.Responded to true:
await promptContext.Context.SendActivityAsync(new Activity(ActivityTypes.Event));
Option 1.2: nullify the prompt
We may not need to avoid having the prompt call its OnPromptAsync if the specific prompt type allows a way to avoid reprompting inside OnPromptAsync. Again having a look at the source code but this time in TextPrompt.cs, we can see where OnPromptAsync does its reprompting:
if (isRetry && options.RetryPrompt != null)
{
await turnContext.SendActivityAsync(options.RetryPrompt, cancellationToken).ConfigureAwait(false);
}
else if (options.Prompt != null)
{
await turnContext.SendActivityAsync(options.Prompt, cancellationToken).ConfigureAwait(false);
}
So if we don't want to send any activities to the user (visible or otherwise), we can stop a text prompt from reprompting simply by setting both its Prompt and RetryPrompt properties to null:
promptContext.Options.Prompt = null;
promptContext.Options.RetryPrompt = null;
Option 2: return true
The second opportunity to cancel dialogs as we move up the call stack from the validator function is in the next waterfall step, like you mentioned in your question. This may be your best option because it's the least hacky: it doesn't depend on any special understanding of the internal SDK code that could be subject to change. In this case your whole validator function could be as simple as this:
private Task<bool> ValidateAsync(PromptValidatorContext<string> promptContext, CancellationToken cancellationToken)
{
if (promptContext.AttemptCount > 3 || IsCorrectPassword(promptContext.Context.Activity.Text))
{
// valid user input
// or continue to next step anyway because of too many attempts
return Task.FromResult(true);
}
// invalid user input
// when there haven't been too many attempts
return Task.FromResult(false);
}
Note that we're using a method called IsCorrectPassword to determine if the password is correct. This is important because this option depends on reusing that functionality in the next waterfall step. You had mentioned needing to save information in TurnState but this is unnecessary since everything we need to know is already in the turn context. The validation is based on the activity's text, so we can just validate that same text again in the next step.
Option 2.1: use WaterfallStepContext.Context.Activity.Text
The text that the user entered will still be available to you in WaterfallStepContext.Context.Activity.Text so your next waterfall step could look like this:
async (stepContext, cancellationToken) =>
{
if (IsCorrectPassword(stepContext.Context.Activity.Text))
{
return await stepContext.NextAsync(null, cancellationToken);
}
else
{
await stepContext.Context.SendActivityAsync("Cancelling all dialogs...");
return await stepContext.CancelAllDialogsAsync(cancellationToken);
}
},
Option 2.2: use WaterfallStepContext.Result
Waterfall step contexts have a builtin Result property that refers to the result of the previous step. In the case of a text prompt, it will be the string returned by that prompt. You can use it like this:
if (IsCorrectPassword((string)stepContext.Result))
Option 3: throw an exception
Going further up the call stack, you can handle things in the message handler that originally called DialogContext.ContinueDialogAsync by throwing an exception in your validator function, like CameronL mentioned in the deleted portion of their answer. While it's generally considered bad practice to use exceptions to trigger intentional code paths, this does closely resemble how retry limits worked in Bot Builder v3, which you mentioned wanting to replicate.
Option 3.1: use the base Exception type
You can throw just an ordinary exception. To make it easier to tell this exception apart from other exceptions when you catch it, you can optionally include some metadata in the exception's Source property:
if (promptContext.AttemptCount > 3)
{
throw new Exception(BotUtil.TooManyAttemptsMessage);
}
Then you can catch it like this:
try
{
await dc.ContinueDialogAsync(cancellationToken);
}
catch (Exception ex)
{
if (ex.Message == BotUtil.TooManyAttemptsMessage)
{
await turnContext.SendActivityAsync("Cancelling all dialogs...");
await dc.CancelAllDialogsAsync(cancellationToken);
}
else
{
throw ex;
}
}
Option 3.2: use a derived exception type
If you define your own exception type, you can use that to only catch this specific exception.
public class TooManyAttemptsException : Exception
You can throw it like this:
throw new TooManyAttemptsException();
Then you can catch it like this:
try
{
await dc.ContinueDialogAsync(cancellationToken);
}
catch (TooManyAttemptsException)
{
await turnContext.SendActivityAsync("Cancelling all dialogs...");
await dc.CancelAllDialogsAsync(cancellationToken);
}

Declare a flag variable in user state class and update the flag inside the if block:
if (promptContext.AttemptCount > 3)
{
\\fetch user state object
\\update flag here
return true;
}
After returning true you will be taken to the next dialog in waterfall step, where you can check the flag value, display an appropriate message and terminate dialog flow. You can refer to microsoft docs to know how to use the User state data

The prompt validator context object is a more specific object only concerned with passing or failing the validator.
** removed incorrect answer **

You can create a class with a WaterfallStep and a PromptValidator. That class would (i) handle the logic to exit the PromptValidator and (ii) handle the logic to cancel/end/proceed the dialog after that. This solution is category of Kyle Delaney answer which returns true in the PromptValidator.
I called that class WaterfallStepValidation:
private readonly Func<string, Task<bool>> _validator;
private readonly int _retryCount;
private bool _isInputValid = false;
public WaterfallStepValidation(Func<string, Task<bool>> validator, int retryCount)
{
_validator = validator;
_retryCount = retryCount;
}
public async Task<DialogTurnResult> CheckValidInputStepAsync(WaterfallStepContext stepContext, CancellationToken cancellationToken)
{
if (!_isInputValid)
{
await stepContext.Context.SendActivityAsync("Could not proceed...");
// Here you could also end all dialogs or just proceed to the next step
return await stepContext.EndDialogAsync(false);
}
return await stepContext.NextAsync(stepContext.Result, cancellationToken);
}
public async Task<bool> PromptValidatorAsync(PromptValidatorContext<string> promptContext, CancellationToken cancellationToken)
{
_isInputValid = await _validator(promptContext.Recognized.Value);
if (!_isInputValid && promptContext.AttemptCount >= _retryCount)
{
_isInputValid = false;
return true;
}
return _isInputValid;
}
And then you call it like this:
var ageStepValidation = new WaterfallStepValidation(AgeValidator, retryCount: 3);
AddDialog(new TextPrompt("AgeTextPromptId", ageStepValidation.PromptValidatorAsync));
var waterfallSteps = new List<WaterfallStep>()
{
PromptNameStepAsync,
PromptAgeStepAsync,
ageStepValidation.CheckValidInputStepAsync,
PromptChoicesStepAsync
};
AddDialog(new WaterfallDialog(nameof(WaterfallDialog), waterfallSteps));
I think this is an elegant workaround for this problem.
The weak points of this aproch are:
you have to place CheckValidInputStepAsync right after the step with the validation
is still a kind of hack, since the PromptValidator returns true if fails the validation
However, the strong points are:
it doesn't make big hacks, just that return true
most of the logic is encapsulated in the WaterfallStepValidation class

Botframework DirectLineClient.Conversations.PostActivityAsync returns null

I'm trying to send an activity through DirectLineClient library to my bot :
var directLineClient = new DirectLineClient($"{secret}");
directLineClient.BaseUri = new Uri($"https://directline.botframework.com/");
var conversation = await directLineClient.Conversations.StartConversationAsync().ConfigureAwait(false);
var activity = new Microsoft.Bot.Connector.DirectLine.Activity();
activity.From = new Microsoft.Bot.Connector.DirectLine.ChannelAccount();
activity.From.Name = "Morgan";
activity.Text = message;
activity.Type = "message";
var resourceResponse = await directLineClient.Conversations.PostActivityAsync(conversation.ConversationId, activity).ConfigureAwait(false);
await ReadBotMessagesAsync(directLineClient, conversation.ConversationId);
resourceResponse is always null.
Edit after Nicolas R answer
I added a method to wait for a response from the bot :
private static async Task ReadBotMessagesAsync(DirectLineClient client, string conversationId)
{
string watermark = null;
while (true)
{
var activitySet = await client.Conversations.GetActivitiesAsync(conversationId, watermark);
watermark = activitySet?.Watermark;
foreach (Microsoft.Bot.Connector.DirectLine.Activity activity in activitySet.Activities)
{
Console.WriteLine(activity.Text);
if (activity.Attachments != null)
{
foreach (Microsoft.Bot.Connector.DirectLine.Attachment attachment in activity.Attachments)
{
Console.WriteLine(attachment.ContentType);
}
}
}
if (activitySet.Activities.Count > 0)
{
return;
}
await Task.Delay(TimeSpan.FromSeconds(1)).ConfigureAwait(false);
}
}
But I never get out of ReadBotMessagesAsync.
I precise that I can communicate with my bot through HTTP request (tested with Postman), and it should be sending a response message whenever a message is sent.

Edited after OP precision
Methods always returns null
Based on the documentation/samples, it looks like this PostActivityAsync return is never used so the value may not be relevant.
From the samples:
await client.Conversations.PostActivityAsync(conversation.ConversationId, userMessage);
See example here.
For those who want more details, because this answer is only limited to the comparison with the sample use, this package is sadly not open-source: https://github.com/Microsoft/BotBuilder/issues/2756
Remarks (for those who would be using the wrong packages)
I would not recommend to use this DirectLineClient Nuget package located here:
https://www.nuget.org/packages/DirectLineClient as it is not maintained since May 2016 and the Bot Framework has changed a lot since that time.
Moreover, it is using DirectLine API 1.0, which is not the best practice at the time. See documentation here:
Important
This article introduces key concepts in Direct Line API 1.1 and
provides information about relevant developer resources. If you are
creating a new connection between your client application and bot, use
Direct Line API 3.0 instead.

C# BotFramework FormFlow, pass values to an external api

I am currently developing a simple c# formflow bot that captures the values and sends those values off to an external api, gets the json data back from the external api and creates Card Attachments based on the results returned. I am making the call to the external api in the OnCompletion delegate as follows, To keep it simple I am not passing any values to the api (For testing purposes)
.OnCompletion(async (context, profileForm) =>
{
var reply = context.MakeMessage();
var carsFromApi = await GetCarsAsync("/api/values");
reply.AttachmentLayout = AttachmentLayoutTypes.Carousel;
reply.Attachments = GetCards(carsFromApi);
await context.PostAsync(reply);
// Tell the user that the form is complete
})
I make the call to the api and store the results in "carsFromApi" , I step into that which is the following code snippet
private static async Task<List<Car>> GetCarsAsync(string path)
{
List<Car> car = new List<Car>();
HttpResponseMessage response = await client.GetAsync(path);
if (response.IsSuccessStatusCode)
{
car = await response.Content.ReadAsAsync<List<Car>>();
}
return await response.Content.ReadAsAsync<List<Car>>();
}
Problem is when I press F10 and go to the next line which is "reply.AttachmentLayout = AttachmentLayoutTypes.Carousel;". The local variable that stored the cars "carsFromApi " is now null. This is the part where it all falls over. I cant pass this "carsFromApi" to "reply.Attachments = GetCards(carsFromApi);" I have tried to store the data in a private variable but that also seems to be null. The external api is working because it just returns a list of static text for now. Any ideas? Thanks in advance.

Based on what you are describing it sounds that your code is not existing through the path of the if (response.IsSuccessStatusCode). Check if that point is reached as I suspect an exception or something is going wrong with the request.
Alternatively, you can try doing the request in the ResumeAfter<T> method you specified when calling the Form instead of that in the OnCompletion delegate

FormFlow and suggested action

I am using FormFlow with enums to render some questions but it seems that formflow is rendering them as a HeroCard with buttons, I'd like the prompts to render as suggested actions so the show as quick replies in FB, what would be the best way of doing this?
For now, I implemented a custom prompter as follows but like to know if there's a better way of doing this with attributes so I don't need to write custom code.
private static async Task<FormPrompt> Prompter(IDialogContext context, FormPrompt prompt, JObject state, IField<JObject> field)
{
IMessageActivity promptMessage;
// Handle buttons as quick replies when possible (FB only renders 11 quick replies)
if (prompt.Buttons.Count > 0 && prompt.Buttons.Count <= 11)
{
// Build a standard prompt with suggested actions.
promptMessage = context.MakeMessage();
promptMessage.Text = prompt.Prompt;
var actions = prompt.Buttons.Select(button => new CardAction
{
Type = ActionTypes.ImBack,
Title = button.Description,
Value = button.Description
})
.ToList();
promptMessage.SuggestedActions = new SuggestedActions(actions: actions);
}
else
{
promptMessage = await Extensions.GetDefaultPrompter(context, prompt);
}
await context.PostAsync(promptMessage);
return prompt;
}

If you want this functionality than you will have to stick to your implementation. Formflow tries to be as abstract as possible and presenting the enum options as a Herocard with buttons is just a result of that. It does this because almost all channels support Herocards and only facebook supports quick replies.

Terminate all dialogs and exit conversation in MS Bot Framework when the user types "exit", "quit" etc

I can't figure out how to do the a very simple thing in MS Bot Framework: allow the user to break out of any conversation, leave the current dialogs and return to the main menu by typing "quit", "exit" or "start over".
Here's the way my main conversation is set up:
public async Task<HttpResponseMessage> Post([FromBody]Activity activity)
{
try
{
if (activity.Type == ActivityTypes.Message)
{
UserActivityLogger.LogUserBehaviour(activity);
if (activity.Text.ToLower() == "start over")
{
//Do something here, but I don't have the IDialogContext here!
}
BotUtils.SendTyping(activity); //send "typing" indicator upon each message received
await Conversation.SendAsync(activity, () => new RootDialog());
}
else
{
HandleSystemMessage(activity);
}
}
I know how to terminate a dialog with context.Done<DialogType>(this);, but in this method, I do not have access to the IDialogContext object, so I cannot call .Done().
Is there any other way to terminate the whole dialog stack when the user types a certain message, other than adding a check for that in each step of all dialogs?
Posted bounty:
I need a way to terminate all IDialogs without using the outrageous hack that I've posted here (which deletes all user data, which I need, e.g. user settings and preferences).
Basically, when the user types "quit" or "exit", I need to exit whatever IDialog is currently in progress and return to the fresh state, as if the user has just initiated a conversation.
I need to be able to do this from MessageController.cs, where I still do not have access to IDialogContext. The only useful data I seem to have there is the Activity object. I will be happy if someone points out to other ways to do that.
Another way to approach this is find some other way to check for the "exit" and "quit" keywords at some other place of the bot, rather than in the Post method.
But it shouldn't be a check that is done at every single step of the IDialog, because that's too much code and not even always possible (when using PromptDialog, I have no access to the text that the user typed).
Two possible ways that I didn't explore:
Instead of terminating all current IDialogs, start a new conversation
with the user (new ConversationId)
Obtain the IDialogStack object and do something with it to manage the dialog stack.
The Microsoft docs are silent on this object so I have no idea how to get it. I do not use the Chain object that allows .Switch() anywhere in the bot, but if you think it can be rewritten to use it, it can be one of the ways to solve this too. However, I haven't found how to do branching between various types of dialogs (FormFlow and the ordinary IDialog) which in turn call their own child dialogs etc.

PROBLEM BREAKDOWN
From my understanding of your question, what you want to achieve is to reset the dialog stack without completely destroy the bot state.
FACTS (from what I read from github repository)
How the framework save the dialog stack is as below:
BotDataStore > BotData > DialogStack
BotFramework is using AutoFac as an DI container
DialogModule is their Autofac module for dialog components
HOW TO DO
Knowing FACTS from above, my solution will be
Register the dependencies so we can use in our controller:
// in Global.asax.cs
var builder = new ContainerBuilder();
builder.RegisterModule(new DialogModule());
builder.RegisterModule(new ReflectionSurrogateModule());
builder.RegisterModule(new DialogModule_MakeRoot());
var config = GlobalConfiguration.Configuration;
builder.RegisterApiControllers(Assembly.GetExecutingAssembly());
builder.RegisterWebApiFilterProvider(config);
var container = builder.Build();
config.DependencyResolver = new AutofacWebApiDependencyResolver(container);
Get the Autofac Container (feel free to put anywhere in your code that you're comfortable with)
private static ILifetimeScope Container
{
get
{
var config = GlobalConfiguration.Configuration;
var resolver = (AutofacWebApiDependencyResolver)config.DependencyResolver;
return resolver.Container;
}
}
Load the BotData in the scope
Load the DialogStack
Reset the DialogStack
Push the new BotData back to BotDataStore
using (var scope = DialogModule.BeginLifetimeScope(Container, activity))
{
var botData = scope.Resolve<IBotData>();
await botData.LoadAsync(default(CancellationToken));
var stack = scope.Resolve<IDialogStack>();
stack.Reset();
await botData.FlushAsync(default(CancellationToken));
}
Hope it helps.
UPDATE 1 (27/08/2016)
Thanks to #ejadib to point out, Container is already being exposed in conversation class.
We can remove step 2 in the answer above, in the end the code will look like
using (var scope = DialogModule.BeginLifetimeScope(Conversation.Container, activity))
{
var botData = scope.Resolve<IBotData>();
await botData.LoadAsync(default(CancellationToken));
var stack = scope.Resolve<IDialogStack>();
stack.Reset();
await botData.FlushAsync(default(CancellationToken));
}

Here is a horribly ugly hack that works. It basically deletes all user data (which you might actually need) and this causes the conversation to restart.
If someone knows a better way, without deleting user data, please please share.
public async Task<HttpResponseMessage> Post([FromBody]Activity activity)
{
try
{
if (activity.Type == ActivityTypes.Message)
{
//if the user types certain messages, quit all dialogs and start over
string msg = activity.Text.ToLower().Trim();
if (msg == "start over" || msg == "exit" || msg == "quit" || msg == "done" || msg =="start again" || msg == "restart" || msg == "leave" || msg == "reset")
{
//This is where the conversation gets reset!
activity.GetStateClient().BotState.DeleteStateForUser(activity.ChannelId, activity.From.Id);
}
//and even if we reset everything, show the welcome message again
BotUtils.SendTyping(activity); //send "typing" indicator upon each message received
await Conversation.SendAsync(activity, () => new RootDialog());
}
else
{
HandleSystemMessage(activity);
}
}

I know this is a little old, but I had the same problem and the posted solutions are no longer the best approaches.
I'm not sure since what version this is available, but on 3.8.1 you can register IScorable services that can be triggered anywhere in the dialog.
There is a sample code that shows how it works, and it does have a "cancel" global command handler:
https://github.com/Microsoft/BotBuilder-Samples/tree/master/CSharp/core-GlobalMessageHandlers
A part of the code will look like this:
protected override async Task PostAsync(IActivity item, string state, CancellationToken token)
{
this.task.Reset();
}

Additional code that worked for someone else:
private async Task _reset(Activity activity)
{
await activity.GetStateClient().BotState
.DeleteStateForUserWithHttpMessagesAsync(activity.ChannelId, activity.From.Id);
var client = new ConnectorClient(new Uri(activity.ServiceUrl));
var clearMsg = activity.CreateReply();
clearMsg.Text = $"Reseting everything for conversation: {activity.Conversation.Id}";
await client.Conversations.SendToConversationAsync(clearMsg);
}
This code is posted by user mmulhearn here: https://github.com/Microsoft/BotBuilder/issues/101#issuecomment-316170517

I know this is an old question, but I got here so... It seems like the 'recommended' way to handle interruptions is to use a Main dialog as the entry point to your bot and then make that main dialog inherit some kind of Cancel/Help dialog whose OnContinueDialogAsync function gets called first. There you can call CancelAllDialosAsync from the DialogContext provided in the parameter.
Read more here https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-howto-handle-user-interrupt?view=azure-bot-service-4.0&tabs=csharp