Proactive Message Delay in Client

[cxbuilders]

This is a bit of an overlapping issue between Sdk / Composer / Client, however posting it here.

I have developed an handoff integration with Genesys that is built around a websocket that calls ContinueConversationAsync when a new message arrives from the agent :

private async Task SendActivity(string eventName, string text = null, object data = null)
{
    await DialogContext.Context.Adapter.ContinueConversationAsync(_claimsIdentity, _conversationReference, new BotCallbackHandler(async (turnContext, cancellationToken) =>
    {
        turnContext.Activity.Type = ActivityTypes.Event;
        turnContext.Activity.Name = eventName;
        turnContext.Activity.Text = text;
        turnContext.Activity.Value = data;
        await _callbackHandler(turnContext, cancellationToken);
    }), default);
}

This is then picked up in Composer and send to the user:

The speed at which the message arrives at the client (emulator in this scenario) is within a second. However before it is actually displayed another 6 seconds pass.

So in the screenshot below the yellow marked "ola" arrives almost instantaneously but 6 seconds pass before it is displayed in the chat itself.

What is causing this?

[srinaath]

@cxbuilders Do you experience the same when using the integrated webchat experience in Composer?

[v-kydela]

@cxbuilders - I wonder if this might be related to the rendering issue I reported here: microsoft/BotFramework-Emulator#2262

I can see that they're not the same issue, because you're saying the activity appears in the log at the right time and doesn't appear in the transcript until later, and in my issue you can see that the messages appear in the log and the transcript at the same time. However, this definitely still looks like a client issue. Try it in Web Chat and other channels just to be sure.

@srinaath - I see that you assigned me. What would you like me to do about this bug?

[cxbuilders]

@v-kydela I don't think that's related as the delay does not occur when the bot is responding to a user activity. On the webchat it's the same, if it would only be emulator it would not be a problem.

[v-kydela]

@cxbuilders - Do you have a minimal example that can help us reproduce this problem? Does this only occur when you're using your Genesys handoff integration, or can you reproduce it with an ordinary proactive message?

[cxbuilders]

@v-kydela This happens with any proactive message, I have seen this happening with notification style messages from external systems, but that was never an issue. Direct chat between agent and user is ofcourse.

I don't have a minimal example, however I think a Custom Action with a loop in it that sends every 10 seconds or so an event that is picked up by Composer would do, as the emulator allows you to clearly see the delay between incoming and displaying

[cxbuilders]

@srinaath Yes the integrated webchat does the exact same thing, steady 6/7 sec delay

[v-kydela]

@cxbuilders - Have you determined that the problem is specific to Composer? Have you tried this with a non-Composer bot? Have you tried sending messages with Postman?

[cxbuilders]

@v-kydela I created a minimal example bot that has a custom component that loops and sends an event activity every 10 seconds. You can see that when the activity arrives in the Emulator log, it still takes a good 5 / 6 seconds for it to show up.

http://cxbuilders.com/temp/ProActiveDelay.zip

[v-kydela]

@cxbuilders - It looks like you've shared a Composer project. I tried starting your project in Composer and it failed to build. What version of Composer would you like me to try with?

[cxbuilders]

@v-kydela This is the latest 1.4.0 Just tested it again and runs without issues (except the one this issue is about :) )

[v-kydela]

@cxbuilders - I can reproduce your problem now. I had a look at your custom action code:

private async Task SendActivity(DialogContext dc)
{
    _claimsIdentity = dc.Context.TurnState.Get<ClaimsIdentity>("BotIdentity");
    _callbackHandler = dc.Context.TurnState.Get<BotCallbackHandler>("Microsoft.Bot.Builder.BotCallbackHandler");
    _conversationReference = dc.Context.Activity.GetConversationReference();
    int _counter = 1;

    while (true)
    {
        await dc.Context.Adapter.ContinueConversationAsync(_claimsIdentity, _conversationReference, new BotCallbackHandler(async (turnContext, cancellationToken) =>
        {
            turnContext.Activity.Type = ActivityTypes.Event;
            turnContext.Activity.Name = "Notification";
            turnContext.Activity.Text = "notification #" + _counter.ToString();
            await _callbackHandler(turnContext, cancellationToken);
        }), default);

        await Task.Delay(10000);
        _counter++;
    }            
}

This looks very unusual to me. Can you perhaps explain why you're doing this this way? Where did you get the idea to get the ClaimsIdentity and the BotCallbackHandler from the turn state? Why are you sending a reply by calling a saved callback handler instead of just using the turn context? Is there a sample that does things like that?

I know it's generally a bad idea to modify the incoming activity like that, but I have no idea if that's related to the problem.

[cxbuilders]

@v-kydela The Custom Action runs a-synchronic, so to mimic incoming agent messages, which are unrelated to incoming user messages and therefore there is no turn present.

This is the same principal as a pro active message. This is the same code @Stevenic used in his proactive teams message sample in microsoft/BotFramework-Composer#4093