You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Admin/Omnichannel/Sessions, we have Livechat_agent_leave_action_timeout configured at 10 or 600 seconds.
We start a Livechat conversation between Guest1 and Agent1 (bot).
Guest1 closes Livechat (closes browser) so the conversation remains open.
We force a logout-login in Agent1, expecting that after 10 or 600 seconds, the conversation closes.
Expected behavior:
After 10 or 600 seconds, Agent1 closes the conversation, so in Omnichannel/Chat History we will see:
Actual behavior:
Expected behavior was working until Rocket.Chat 3.3.3. Since Rocket.Chat 3.4.0, nothing happens. The conversation reamains open:
Server Setup Information:
Version of Rocket.Chat Server: 3.4.2
Operating System: Ubuntu 18.04
Deployment Method: tar
Number of Running Instances: 1
DB Replicaset Oplog: true
NodeJS Version: 12.16.1
MongoDB Version: 4.0.13
Client Setup Information
Desktop App or Browser Version: Chrome 83.0.4103.116
Operating System: Windows 10
Additional context
As I mentioned before, this issue happens with 3.4.0, 3.4.1 and 3.4.2. We still have another server with 3.3.3 where we still have the expected behavior.
We also think that maybe this could be something similar to another issue #18132 which started in 3.4.0 but was resolved in 3.4.1.
Relevant logs:
N/A
The text was updated successfully, but these errors were encountered:
Description:
Omnichannel/Sessions chat closed not working.
Steps to reproduce:
Expected behavior:
After 10 or 600 seconds, Agent1 closes the conversation, so in Omnichannel/Chat History we will see:
Actual behavior:
Expected behavior was working until Rocket.Chat 3.3.3. Since Rocket.Chat 3.4.0, nothing happens. The conversation reamains open:
Server Setup Information:
Client Setup Information
Additional context
As I mentioned before, this issue happens with 3.4.0, 3.4.1 and 3.4.2. We still have another server with 3.3.3 where we still have the expected behavior.
We also think that maybe this could be something similar to another issue #18132 which started in 3.4.0 but was resolved in 3.4.1.
Relevant logs:
N/A
The text was updated successfully, but these errors were encountered: