MessagingService.oldMessages is not fired whem there is an existing session

[IvanDg]

We are using headless SDK and would like to ask if this is a correct behavior based from our understanding of the API when there is an existing session.
We have 3 observations when the load of our custom web messenger is slow enough.

1. When our loading is slow, sometimes the following is observed (OK case)
   • MessagingService.ready is fired
     -MessagingService.started is fired
     -When started is fired, our script invoke MessagingService.fetchHistory
     -MessagingService.oldMessages is fired
2. When our loading is slow same as #1, sometimes the following is observed (NG case) when our subscription to Genesys events are too late I assume.
   -MessagingService.ready is refired
   -MessagingService.started is not refired -> This is inteded as per Genesys
   -Our script tries to start a conversation but since a session exists it rejects and our script invokes MessagingService.fetchHistory
   -MessagingService.fetchHistory is resolved to fire MessasgingService.oldMessages as per logs
   -MessagingService.oldMessages is not fired -> NG?
   -Now our messenger doesn't have any chat history.
   Note: On refresh, it seems our cache made the login fast enough that everything is restored
   
   

This is our fetchHistory code:
Genesys(
'command',
'MessagingService.fetchHistory',
() => console.log('Messaging fetched OK'),
() => console.log('Messaging history complete'),
() => console.log('Messaging error'),
() => console.log('No active conversation'),
);

[IvanDg]

Supplementing my understanding of what happens as this happens like 50% of the time when there is an exisitng session:

1. I started a web messaging session.
2. The session is fine
3. I refresh the page, our custom script that subscribe to MessagingService events are delayed(complicated systems with lots of things being loaded)
4. While our custom script is still loading, the started events and the oldMessages(page 1) is event is fired.
5. Now our script loaded and already too late to accept the started event and oldMessage event.
6. MessagingService.ready is refired
7. Our script then start the Messenger, but since there is an existing session, it will reject
8. Our script will catch this reject and fetchHistory again and the historyCompleted(page 2) is fired.

Any thoughts on this? Our messenger is stuck with no message at all. The users can still chat but the history is not there.
I feel like it makes sense that MessagingService.started and MessagingService.oldMessages will also refire or maybe we get to pick which page we wanted to fetch..

[Ranjith_Manikante_Sa]

Hi @IvanDg,

We are looking into this late subscribing to events use case and will get back shortly. In the meantime, may I ask what is the reason for calling MessagingService.fetchHistory every time MessagingService.started event is fired? That looks redundant because, when it is not a new conversation restoring automatically happens and MessagingService.restored event is published along with the first set of latest messages. You could subscribe to this event and get the messages to show them in the chat transcript.

The idea behind MessagingService.fetchHistory is only to fetch even older messages if any that aren't available in the MessagingService.restored event.

Thanks,
Ranjith Sai

[IvanDg]

Hello @Ranjith_Manikante_Sa,
Thank you! Hope to hear from you soon
We are looking at a workaround to have our consumers subscribe to Genesys events but it is pretty much messy and have lots of things to check. And we don't want our custom UI messenger consumer to have subscriptions of Genesys events. So I don't think this is the right thing to do.
We are calling MessagingService.fetchHistory as we never used MessagingService.restored before. We will check on this on our side. Thank you for pointing that out.

[Ranjith_Manikante_Sa]

Hi @IvanDg,

We are making changes are our side so that the following events are republished when you subscribe to them later after they are published.

• MessagingService.started
• MessagingService.restored

We are hoping this change will help in your use case, ensuring these events are republished similar to MessagingService.ready event. You can follow up with the care team to determine when this change will be out.

When using Messenger Headless SDK, it is required to make use of all the events by subscribing to them as needed. Only depending on the commands may not address all the needs in building your own custom UI Messenger.

[IvanDg]

Hello @Ranjith_Manikante_Sa, Thank you for your response!
I am glad this will be solved and looking forward to this fix. We are using the MessagingService.restored in our latest release and this will automatically fixed the issue.