Repository navigation
[DF blackout window] timer to release a stuck blackout window. #1225
Description
We are seeing an occassional issue in Prod described here: #1158
Our logs do not show any failed HTTP requests, or anything at all, except that the visitor is in a blackout window. The CX logs are not showing anything either, so it is as if Rocketchat is not sending a response to the zeroTimerPayload, specifically in the 'boletoPause' case.
As a backstop, we should consider a timeout value for all blackout windows. If a response is not received from CX after 30 minutes (or some configured time) then release the blackout window. This will improve the user experience and and eventually allow the user to get unstuck.
Metadata
Metadata
Assignees
Labels
No labels
Activity
ear-dev commentedon Jun 16, 2022
Timer on HTTP timeouts, or after a configured timeout value.
ear-dev commentedon Jun 23, 2022
NOTE: need to handle payloads from CX.agent that include 'continue_blackout'. continue_blackout resets the timer as well.
timeout_value = 120seconds
[-][DF blackout window] timer to release a stuck blackout window.[/-][+][DF blackout window][Priority] timer to release a stuck blackout window.[/+]AlexanderKanakis commentedon Jun 30, 2022
PRs:
Apps.Dialogflow: WideChat/Apps.Dialogflow#160
ear-dev commentedon Jul 14, 2022
@AlexanderKanakis @Shailesh351 we are seeing an issue where this feature works once, but fails a second time within the same session. We demo'd that at the meeting today.
@Shailesh351 Can we look at the logs in kibana to try and understand the series of events please?
Observation: In the case where the feature works the first time, we seem to be interfering with the original timer event from DF (180sec in our testbot test case) i.e. we never see that job get cancelled or executed. At this point we might be in a bad state.
ear-dev commentedon Jul 14, 2022
@AlexanderKanakis please add a log point which includes the roomID to when your timeout event gets executed.
ear-dev commentedon Jul 14, 2022
@AlexanderKanakis Since we already merged your drop queue branch into master, when you are making the fixes and adding the log point we discussed, please make a new branch and open a new PR. I think you may have pushed some fixes to the original feature branch you were working on? But instead of opening a new PR on that branch, it is better to have a new branch please. Thanks.
AlexanderKanakis commentedon Jul 18, 2022
New PR with fixes: WideChat/Apps.Dialogflow#162
ear-dev commentedon Aug 2, 2022
NOTE: We rolled this fix back out of master. We are going to put this back in the backlog and address it later. @AlexanderKanakis when we decide to do it again you will need to port all changes to a new feature branch. Sorry for the confusion and extra work.
[-][DF blackout window][Priority] timer to release a stuck blackout window.[/-][+][DF blackout window] timer to release a stuck blackout window.[/+]