[Brazil] integrate with Dialogflow CX's 'partial response' fuctionality

[ear-dev]

Alexander has described the issues involved in issue number 809..... use this as starting point for discussion.

[ear-dev]

Steve will check with google about an updated version of the nodejs module for the API.

If we go this route, we will need to refactor all communication between our app and the CX.agent

[ear-dev]

@Shailesh351 can you look at this and concur.

[ear-dev]

@AlexanderKanakis we will go with your current strategy into production for now...... please create the other neccessary PRs to make this work, and document that here.

Also please document the effects of large responses vs. small, and how you are suggesting we use partial responses vs. normal responses on the CX.agent

[ear-dev]

@AlexanderKanakis please document you new strategy here. Include any gottchas and weird errors....

[AlexanderKanakis]

PRs:

1. RC: [FIX] Add missing function in AppActivationBridge #1072
2. Apps.Dialogflow: [EXTEND] Parse partial responses Apps.Dialogflow#132
3. RC.Apps-engine: Import Dialogflow CX Rocket.Chat.Apps-engine#47

Instructions:

Run npm install @rocket.chat/apps-engine in both Rocket.Chat and Apps.Dialogflow repos.

[ear-dev]

@AlexanderKanakis not sure I understand the instruction to run npm install @rocket.chat/apps-engine
Shouldn't that just be a part of the package.json in those repos?

[AlexanderKanakis]

@ear-dev For some reason @rocket.chat/apps-engine may not update properly if updated through the npm install or meteor npm install command. I found that installing @rocket.chat/apps-engine specifically solves the problem.

[ear-dev]

This seems odd to me...... if it's part of package.json, and one were to just delete the current node_modules directory, and the current package-lock.json, and run meteor npm install again, everything should load as described in package.json.

I see that your dependency changes in the related PRs here, are adding changes to package-lock.json, but not to package.json, and I'm not sure I understand how that is supposed to work. i.e. if something is in package-lock.json, but it is not represented in package.json, that should remove the entries in package-lock.json when we run npm install? Or, are those sub-dependencies from something that is described in package.json?

[AlexanderKanakis]

Oops, I did not specify. They are dependencies that come from @rocket.chat/apps-engine.

[ear-dev]

Still having a hard time getting this to work.... ever see this error?

[ear-dev]

Error occurred while sending a HTTP Request: { roomID: shYxGmd9cNkwAyb4o } {"stack":"TypeError: $s is not a constructor\n at It.detectStreamingIntent (evalmachine.<anonymous>:8:1361)\n at runMicrotasks (<anonymous>)\n at processTicksAndRejections (internal/process/task_queues.js:97:5)\n at It.sendRequest (evalmachine.<anonymous>:1:23383)\n at yo.run (evalmachine.<anonymous>:8:23852)\n at $o.executePostMessageSent (evalmachine.<anonymous>:8:29048)","message":"$s is not a constructor"}

[ear-dev]

@Shailesh351 can you review these three PRs please and test it out when you have a chance? FYI - we have a test CX bot that includes a test for partial responses.... I'm working on providing you all the config.json that will point to that test agent.

[ear-dev]

@AlexanderKanakis @Shailesh351 it sounds like we need to adjust the current blackout window for partial responses. 'if partial_respnse: wait for last response'

[ear-dev]

NOTE: blackout_window in effect until the final response from CX. queue_window still applies as designed for events.

blackout_window == drop all visitor messages
queue_window == send only the last visitor message if there is a queue

please document which payloads can be processed by rocketchat during the middle of a series of partial responses. MOTIVATION: we want to protect against CX developer user error.

[AlexanderKanakis]

Custom Payloads:

Partial responses will not be able to handle payloads that require sending additional requests to the DF agent for any non-FINAL responses (the final message of a stream).

Currently supported Custom Payloads:

1. df_set_timeout
2. change_language_code
3. drop_queue

[ear-dev]

@Shailesh351 @AlexanderKanakis I tested this out against our testbot test case and it worked well! Nice! @Shailesh351 can you please have a look at all three relevant PRs in this issue and review/approve when you have some time? Thanks! This will ultimately replace our use of 0 second timers.....