If websocket is enabled there is no chat history on page reload

[rcha37]

If websockets are enabled than on page reload chat history is not getting displayed.

The tutorial followed for getting chat history with websocket is https://docs.microsoft.com/en-us/bot-framework/rest-api/bot-framework-rest-direct-line-3-0-receive-activities. This works when we are using HTTP (with websockets set to false) using the botchat.js client side code. But if websocket is enabled the history is not displayed.

[kushalbhabra]

Hi, I'm facing same issue, did it get resolved for you?

[rcha37]

Issue still exists with websockets.

[rafaelmaeuer]

Is there any news on this? I would like to use websocket to avoid http pulling and to get typing bubbles. At the moment I am forced to disable websocket because I didnt found any other solution for using chat history so far. Furthermore I want to now, how chat history is stored by directline and for which amount of time? Is there another way to store chat history e.g. in my own database to restore it on page load? Then I would have full control about message data and display behaviors. And another question: will the Bot State Service deprecation (31.03.2018) affect the chat history stored by directline?

[rcha37]

There is no update yet. For chat history websocket needs to be used only for now. You can store chat history by intercepting messages https://docs.microsoft.com/en-us/bot-framework/nodejs/bot-builder-nodejs-intercept-messages.

[vincec-msft]

A fix for this was rolled out on Direct Line earlier this month. If you're still seeing the issue please post a HAR file demonstrating the issue. Thanks.

[baki32]

Hi,
I just tried it and I'm still not getting history after page refresh when web sockets are enabled in web chat.

I don't want to upload HAR files here as directline secret is inside

[vincec-msft]

Are you sure the 2 instances of webchat are using the same conversation id?

[baki32]

Yes, it’s working fine as log as I keep webSocket param set to false

…

Sent from my Windows 10 phone

________________________________ From: vincec-msft <notifications@github.com> Sent: Thursday, May 3, 2018 4:05:46 PM To: Microsoft/BotFramework-WebChat Cc: baki32; Comment Subject: Re: [Microsoft/BotFramework-WebChat] If websocket is enabled there is no chat history on page reload (#850) Are you sure the 2 instances of webchat are using the same conversation id? — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#850 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AVyIlp44pynXrWYJ0MS2bAbiYT7SsHvmks5tuw66gaJpZM4RsphL>.

[baki32]

Sent

[baki32]

For fellow githubers I'm attaching email thread I've had so far with @vincec-msft

---

Hi Vince,
I gave it a try without success – also I found this on DirectLineJS github

Getting any history that Direct Line has cached : you can retrieve history using watermarks: You can see the watermark as an activity 'bookmark'. The resuming scenario will replay all the conversation activities from the watermark you specify. For now, this only works when using the polling version of DirectLine.

import { DirectLine } from 'botframework-directlinejs';

const dl = new DirectLine({
    token: /* the token you retrieved while reconnecting */,
    streamUrl: /* the streamUrl you retrieved while reconnecting */,
    conversationId: /* the conversationid you stored from previous conversation */,
    watermark: /* a watermark you saved from a previous conversation */,
    webSocket: false
});

Watermark with websocket will be supported in the future.

When I supply watermark 0 it is ignored and no history is returned after refresh.

---

I'm not familiar enough with the webchat control to answer your question but one of my sources said, "you can provide your own watermark during initialization of BotConnection object (from DirectLineJS)."

Looks like that's specified in the DirectLineOptions (the same place the conversationid is set).

I'm not sure how much customizing is necessary, but I do know that many people customize the control extensively. The code is here:

https://github.com/Microsoft/BotFramework-WebChat

And the underlying library that handles the interaction with Direct Line is here (although changing it usually isn't necessary):

https://github.com/Microsoft/BotFramework-DirectLineJs

---

We’re using webchat oob javascript code to initiate directline connection, so there’s no control over the requests. If there’s a way I don’t know about it

---

Thanks for the files.

There is a watermark parameter that controls how much of the conversation is replayed when reconnecting. That parameter is blank in the 2nd HAR file and blank means "only messages received after the reconnection request are replayed."

That default behavior is optimizing for the common case where the connection is lost due to a network blip and the client needs to reconnect, but doesn't need the history. Some conversations are very long and replaying them would be inefficient, especially if the client has to throw away messages that it already has.

Request: https://directline.botframework.com/v3/directline/conversations/JVhyhsC2O4095aIoMFPYQB?watermark=

See https://docs.microsoft.com/en-us/azure/bot-service/rest-api/bot-framework-rest-direct-line-3-0-reconnect-to-conversation

You can pass "watermark=-" to replay the entire conversation.

Does that help?

[vincec-msft]

Hmm, I'm not sure why DirectLineJs doesn't support a watermark on a websocket call. There's explicit code in there to block it that I'm betting could just be commented out. My familiarity is with the server side of things and I know for sure that we fixed a bug there in the last month and that a big customer is using history over websockets today. Sorry I can't be of more help, but maybe the webchat or directlinejs devs can be.

[rafaelmaeuer]

How can we get further help by webchat or directlinejs devs here?

[compulim]

@rafaelmaeuer We are working on the conversation preservation/restoration/continuation. That will help in the scenario. It is coming, just need some more time.