Genesys Cloud - Main

There are times when an agent has ended/wrapped-up a chat interaction and a few moments later that interaction comes back to be answered but no customer started it. We are able to reproduce the issue in our lab but it does not happen all the time, happens though frequent enough.

This behaviour has also been noticed by customers of ours (we are the developers of auvious) where their agents answer interactions that just closed but no one is there. 

Things we noticed

• We have 'Clear conversation' enabled and also 'Conversation Disconnect' set to 'Display conversation status and disconnect session'. This means on each new interaction from the same browser tab, we should get a new clean session. However the returning interaction has the chat messages of the previous one.
• A chat message coming from the agent is never delivered. We see a yellow triangle in the Genesys UI and 'delivery-failed' as a status on the POST request of that message. 
  

We have implemented our own widget that uses the Web Messaging Guest API so we are able to see all the messages exchanged to and from the widget. We are using the "echo" method to check for the health of the websocket connection. There are no new messages originating from the widget after the interaction has ended. Also the websocket connection is closed and no echo message is sent after the interaction ended.

Interaction ID that we managed to reproduce it: b1a619dd-e576-4384-99ae-ca3ea1b5ccac
Organization ID (in case you need it) : 6e6d5224-1909-48fa-a982-66cef3fa4c08

region: mypurecloud.de

We also see a  specific error message in the browser console on the agent side that is being repeated. We don't know if that's relevant. 
```
["PureCloud Client Apps - Interapptions - sendMessageByInstanceId failed",{"instanceId":"b7a743cb-0931-48f9-b62e-1f23f28d1e06","remoteData":{"errorMessage":"App instance not found","poolId":"appPoolV2","hostAppName":"web-directory","hostAppVersion":"12.8.0+3-release/12.8.0-c65cec4201df9b4af08c381ff1a1b50ededea490","maxPoolSize":50,"currPoolSize":4,"conversationInteractionCount":1,"conversationTotalConversationAppDefs":1,"conversationTotalConversationFailedApps":0,"conversationTotalConversationRunningApps":1,"conversationTotalContextualAppDefs":5,"conversationTotalContextualRunningApps":3,"conversationTotalContextualFailedApps":0,"currentInteractions":{"1d960772-7cb3-42d3-b5a1-06e52145d1de":{"type":"webmessaging","isActive":true,"conversationAppDefs":1,"conversationRunningApps":1,"conversationFailedApps":0,"contextualAppDefs":5,"contextualRunningApps":3,"contextualFailedApps":0}},"sensitive":{}}},{"activeConversations":["1d960772-7cb3-42d3-b5a1-06e52145d1de"]}]
```

#API/Integrations
#DigitalChannels

------------------------------
Michael Korkaris
Product Manager
------------------------------

Hello Michael, 

I think I can see the problem. The issue appears to be related to session handling and websocket connection management. Even though the clear conversation and conversation disconnect is set to display status and disconnect you might be hitting a race condition in the session handling. 

I got this from looking at a couple of things. The websocket connection is properly closed from your widget side, no new messages originate from the widget after the interaction ends, the "echo" method confirms no active connections, messages show 'delivery-failed' status with yellow triangle in the UI and previous chat messages appearing in new sessions despite clear conversation being enabled. 

Specifically to the error message, it looks like the app instance coordination issue in the agent workspace. The error message also indicates a mismatch between the conversation state and the app instance management. The system is showing active conversations that might not be properly terminated. 

I have some recommendations that may help. 

First lets double check the implementation. Verify that your widget is properly implementing the session clean up on disconnect. Next ensure you're handling the disconnect event properly in your custom widget. Finally implementing proper session state management on your end could help. 

Next lets check up on how you are monitoring. My recommendation is to add logging for websocket connection states. This can be found here. Then monitor the delivery status of messages more closely. Finally track session ids and their lifecycles. 

Since you have a case with the interaction id, I recommend implementing additional logging around the session termination, capture the full sequence of events leading to the ghost interaction. Verify that your implementation properly handles the "closed" response from the server. Ensure your widget waits for the proper closed message without timeout handling before completely terminating the session. 

If all the above doesn't help, my next suggestion would be to open a support case so they can look into the logging on our end as well as the console logs you can provide. 

I would also like to mention that posting in the dev community might be helpful as well. 

Cheers, 

------------------------------
Cameron
Online Community Manager/Moderator
------------------------------

Hi Cameron

Thank you for the suggestions. We will try them out and let you know. 

Regarding the webSocket monitoring, the guide you shared seems to be for the agent side, not the widget side (it requires a user id and we are guests/customers). We have added logging on all the steps possible and we also monitor the webSocket messages from the developer tools. 

The error message I pasted was one of the many we got during testing so most probably it isn't specifically for that interaction ID so don't take it as an indicator. We will check if we get the same error message for another failed interaction.

------------------------------
Michael Korkaris
Product Manager
------------------------------

Original Message:
Sent: 12-03-2025 10:15
From: Cameron Tomlin
Subject: Web Messaging | Closed Interaction gets routed back to agent but noone started it

Hello Michael, 

I think I can see the problem. The issue appears to be related to session handling and websocket connection management. Even though the clear conversation and conversation disconnect is set to display status and disconnect you might be hitting a race condition in the session handling. 

I got this from looking at a couple of things. The websocket connection is properly closed from your widget side, no new messages originate from the widget after the interaction ends, the "echo" method confirms no active connections, messages show 'delivery-failed' status with yellow triangle in the UI and previous chat messages appearing in new sessions despite clear conversation being enabled. 

Specifically to the error message, it looks like the app instance coordination issue in the agent workspace. The error message also indicates a mismatch between the conversation state and the app instance management. The system is showing active conversations that might not be properly terminated. 

I have some recommendations that may help. 

First lets double check the implementation. Verify that your widget is properly implementing the session clean up on disconnect. Next ensure you're handling the disconnect event properly in your custom widget. Finally implementing proper session state management on your end could help. 

Next lets check up on how you are monitoring. My recommendation is to add logging for websocket connection states. This can be found here. Then monitor the delivery status of messages more closely. Finally track session ids and their lifecycles. 

Since you have a case with the interaction id, I recommend implementing additional logging around the session termination, capture the full sequence of events leading to the ghost interaction. Verify that your implementation properly handles the "closed" response from the server. Ensure your widget waits for the proper closed message without timeout handling before completely terminating the session. 

If all the above doesn't help, my next suggestion would be to open a support case so they can look into the logging on our end as well as the console logs you can provide. 

I would also like to mention that posting in the dev community might be helpful as well. 

Cheers, 

------------------------------
Cameron
Online Community Manager/Moderator
------------------------------