Botframework-webchat: Revert synthesized "conversationUpdate" activity

[ryanvolum]

Github issue for C# /JS

Sample information

1. Sample type: Sample
2. Sample language: All languages
3. Sample name: welcome-users

Describe the bug

In the emulator and _most_ other channels, the welcome-users sample proactively welcomes the user when the conversation is initiated. This leads to the (desirable) behavior of the bot giving the user some context of its capabilities before the user types anything. Without a proactive welcome, users are often left in the dark as to what they can/should do.

Unfortunately, when using the same welcome-users sample with webchat (and directline) as a client, the bot's behavior is different - it doesn't send a welcome message until a user says something.

Any divergence in channel capabilities (especially a client/channel as popular as webchat/directline) should be documented. If the emulator uses webchat, and doesn't reflect the actual behavior of webchat, what is it really emulating? Developers tend to build their bot locally, and are then confused as to why it behaves differently when deployed.

To Reproduce

Steps to reproduce the behavior:

1. Create a bot using the welcome-users sample (node, C#)
2. deploy the bot
3. chat with the bot through webchat/directline
4. observe that the bot will not proactively welcome you

Expected behavior

I expect the bot to welcome the user _before_ the user sends any message to the bot in Webchat.

Additional context

This issue of a bot initiating a conversation over directline has existed since the first iteration of the botbuilder. Without a user initiating a conversation, the bot doesn't have a conversationId to correctly route its message. @dandriscoll can probably provide more details! In the past I've implemented a workaround, where on initialization of the directline endpoint, the client sends an "invisible" backchannel event to the bot, which the bot then replies to. Unfortunately, this workaround is not documented and requires complex code changes to both the client and the server.

Also, fwiw, this could have been a bug in the samples repo, botbuilder repo or in webchat
[bug]

[vishwacsena]

we need to make sure that the webchat/ directline behavior has conversation update for user sent up without requiring the user to send a message.

[corinagum]

@ckkashyap this issue is related to past history scenario. Tagging because they're related.

[dividor]

This is a really big issue for us. Thanks.

[compulim]

@dividor I am drafting PR #1286 for this one. High on my list.

[dividor]

Thanks a lot @compulim!

[ryanvolum]

@compulim heads up that the using the webchat code in master we're still seeing behavior that is inconsistent with the emulator's behavior. We're attempting to determine if a user joined the conversation by comparing activity.membersAdded.id to activity.recipient.id, as the welcome-user sample illustrates. We're seeing that we're actually getting two activities with the duplicate ids:

member added:
{ id: 'r_r6349gur4w' }
recipient:
MyChatBot@cR5tv7dWwtI

member added:
{ id: 'r_r6349gur4w' }
recipient:
MyChatBot@cR5tv7dWwtI 

Which means that that check will pass twice. The welcome-users sample also relies on state to determine if it's already sent a welcome message, so it will work as outlined in the sample, however that seems to be a band-aid on top of some kind of race condition or bug. The expected behavior is the behavior that the emulator employs, where we get a membersAdded for our bot and a membersAdded for our user, instead of two for the user.

[compulim]

@ryanvolum Bad decision here, we will backtrack this work of synthesizing a conversationUpdate event (#1608).

Instead, we will direct everyone to use "custom welcome event" (sample here). And we will update docs.microsoft.com to reflect this changes.

[cwhitten]

@ryanvolum @compulim this is known and pending a larger conversation with the Bot Framework Service teams in a consistent message on how to achieve this. The documentation you reference does not align with the modern suggested methods. We should have some direction on this next week.

[compulim]

Moving to 4.4.

[compulim]

Moved back to 4.3.

[gabog]

Thanks @compulim for prioritizing this for 4.3, I agree with @ryanvolum that the emulator and webchat should be consistent, the "custom welcome event" sample is useful but not obvious and it will take people a while to discover it. At the very least for light bots, emulator and webchat should behave the same and have a consistent conversationUpdate message that contains the user ID and allows us to create proactive welcome messages.
In advanced scenarios (most non trivial bots in reality), a developer could implement the custom welcome event pattern (it should be prominently documented) and at this point, you will not be able to use emulator anymore (depending on what you do in your custom event) and will need to move to ngrok, azure service bus or something similar to be able to develop directly from webchat and ensure your custom event gets executed and you can test on something that behaves the same way as the channel you are targeting to ship to.
At some point we looked at ways of adding channelData with location info to conversationUpdate so we could provide a welcome message relevant to the user’s location, but that was not possible then and we ended up going down the custom event from the page that was hosting webchat (something similar to the sample custom event you describe).

[gabog]

Also, for the custom event, it would be nice to have an explicit parameter in the webChat API where the dev can pass a function to be executed on startup so it is consistent and we don't have to reference a sample.

[compulim]

Closed accidentally by PR merge. There are a few documentation work need to be done.

(Thanks @corinagum for reminding me.)

[compulim]

@gabob we refrain from doing that for a few reasons, here is one of them.

• Browser can identify if a function is called due to an user action or not (e.g. clicking on a button)
  
  
  
  • Browser will deny certain privacy-related functions if they are not called as a result of an user action
  
  
• If we provide the "startup" function, it is probably not being called as an user action

Over the cons, the "startup" function do not provide much functionalities, but introducing another API to learn.

[compulim]

For conversationUpdate, it is generated by the Direct Line platform. Thus, there is no way to modify that. We synthesized one, but we reverted it.

Welcome message is interesting pattern, we discover multiple pieces of information that might be interesting to the bot:

• If the hosting page has SSO, the auth token from the page
• Browser language
• Latitude/longitude, we strongly recommend asking the user consent before sending this one
• Local timezone

The list is not exhaustive and they will change from time to time. We need to look at the Emulator model. But what I believe is, for advanced user, they should use their custom version of Web Chat, and connect to Emulator. Emulator will works like Fiddler, than a hosted Web Chat.

[gabog]

Thanks for explanation @compulim , I am personally OK with using conversationUpdate and "custom event pattern" going forward. Will this change go out in the release you guys are planning for the end of the month?

[compulim]

Yes, this PR is in. 😉

Will close this one, and open another one for docs work around "welcome event".

[ryanvolum]

@compulim as of now it appears that the emulator is using the version of webchat that has your original fix. This means that webchat is manufacturing a new conversationUpdate _and_ the emulator shell is manufacting a conversationUpdate. We have some developers using the preview emulator, and it's causing them to receive too many conversationUpdates.

When is your rollback supposed to go live? Is the emulator release next week going to use the rollbacked webchat or is it going to behave the way the preview is behaving right now?

Incidentally, if the emulator goes live as it currently stands, it's going to cause tons of problems.

[compulim]

I believe Emulator picked up a newer Web Chat build (4.3.0) and that would have the behavior reverted (no dupe conversationUpdate).

Should be good.

[ryanvolum]

@compulim the original bug "Welcoming users samples don't work as expected in Web Chat" still holds true since the changes were reverted. Basically, the core issue is that Webchat works differently than the emulator, which is supposed to be emulating Webchat.

Is there an open bug that represents this issue? If not, should we reopen this one and revert the name?

[dandriscoll]

The emulator is designed to emulate channels in general, not just Web Chat.

[ryanvolum]

Thanks @dandriscoll. Is it fair to say that the disparity in conversationUpdate behavior between WebChat and the Emulator is not a bug then?

I'll say that most devs we work with tend to be surprised/assume they did something wrong when they deploy their bot and experience different behavior.

[dandriscoll]

It's not really a bug. Our recommendation for identifying the first appearance of a user (for e.g. welcome messages) is to use internal bot state to track that. This works consistently across channels that have single-join behavior (Facebook, Skype, etc.) group-join behavior (Direct Line, Web Chat, Skype for Business), and none (Email, SMS).

Direct Line and Web Chat will send a ConversationUpdate immediately on user join (like Skype/Facebook/etc.) if you pass a user ID through the token API: https://blog.botframework.com/2018/09/25/enhanced-direct-line-authentication-features/

[cwhitten]

@ryanvolum we'll need to address this in a couple ways given the protocol constraints.

1. The Emulator's Direct Line implementation can't send the conversationUpdate activity for a User when we start a conversation. This doesn't match the protocol.
2. No longer sending that event means we no longer provide a low-friction way to test welcome messaging using the WebChat embed inside the Emulator. We'll need a mechanism to do so via a token API implementation or other means and there needs to be a level of configuration for users here. In a sense this kicks the can down the road, because it introduces a concept that the Emulator provides for them that they'll need to implement before they deploy their bot, which is essentially what we do for them today.

I'd love to wait on this until we can replace the Emulator's Direct Line implementation all-up with the in-proc Direct Line work that @dandriscoll and team are working on.

[ryanvolum]

Thanks @dandriscoll and @cwhitten.

Chris, I agree on both points. In the meantime, the fact that developers are confused about the disparate behavior is an issue in itself. This doc does mention disparity in behavior across channels, but could definitely be more explicit, and could mention @dandriscoll's point:

Direct Line and Web Chat will send a ConversationUpdate immediately on user join (like Skype/Facebook/etc.) if you pass a user ID through the token API: https://blog.botframework.com/2018/09/25/enhanced-direct-line-authentication-features/

It also does encourage a hybrid approach, which uses both bot state and conversationUpdates to welcome users.

I'm happy to move this over to doc-land, and know that there are some changes coming.