[DF blackout window] timer to release a stuck blackout window.

[ear-dev]

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.

[ear-dev]

Timer on HTTP timeouts, or after a configured timeout value.

[ear-dev]

NOTE: need to handle payloads from CX.agent that include 'continue_blackout'. continue_blackout resets the timer as well.

timeout_value = 120seconds

[AlexanderKanakis]

PRs:
Apps.Dialogflow: WideChat/Apps.Dialogflow#160

[ear-dev]

@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]

@AlexanderKanakis please add a log point which includes the roomID to when your timeout event gets executed.

[ear-dev]

@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]

New PR with fixes: WideChat/Apps.Dialogflow#162

[ear-dev]

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.