对话流在三个交互后返回“对不起，我无能为力”消息

Question

This issue started this morning (21 June 2019) affecting ALL our dialogflow agents. Previously they have been working fine, though we had observed this behaviour occasionally over the past month, but found it difficult to reproduce.

Now we can reliably reproduce it and it has hammered all our voice work.

Our webhook returns a piece of json like this to trigger an event to move the user to the next intent:

"followupEventInput": {
    "name": "Textbox",
    "languageCode": "en-AU"
}

The problem is that if we use events more than twice after the initial trigger, the user is just given a message "Sorry, I can't help" and the Agent is forcibly closed.

Example conversation:
"Talk to Foobar Toys"
  "Welcome to Foobar Toys. How can I help you?" (Start app)
"I'd like to know about Lego"
  "Do you want to know about Technic, or Star Wars lego?" (Invocation started)
"Technic"
  "Are you interested in sets or minifigs?" (Interaction 1)
"sets"
  "What kind of sets?" (Interaction 2)
"cars"
  "Sorry, I can't help." (Failure after interaction 2.)

This is very similar behaviour to as if we were using a default fallback intent all the time, but we aren't.

The interactions are all intents triggered by events.

If we DO happen to trigger a fallback intent or help text, the counter resets and we can keep going until we next hit this.

A LOT of our workflows involve more than 2 interactions. So this is a pretty big deal. Any advice appreciated. I've spent a day or two trying to work out a scenario in which this doesn't happen for us with no luck at all.

Answer 1

So, we've worked out what caused this, and have managed to work around it.

Our Agent was composed of several intents that each had a required input parameter called "input." Triggering of the intents via our webhook was done (sometimes) by use of the follow-up event. In FireBase this is achieved by using a statement like:

agent.setFollowupEvent('message');

where "message" is the name of the event that is linked to your intent.

It seems that by taking the workflow out of the hands of the dialogFlow core, we somehow triggered it into thinking that it wasn't managing to match any intents, even though our code was effectively telling it which intent to send the conversation to.

Our workaround for now is to have a single intent that matches on sys.any and not pass back followup events any more.

If anyone is interested, I have a very simple workflow+firebase that reproduces this issue.

Added later - Response from Google

"it seems that the cause of the issue is the slot filling using @sys.any as an entity. Please don't use @sys.any on slot filing as to this is not a standard practice on using @sys.any."

Answer 2

Here was my setup and my hacky fix:

intent1, triggered by event "eventIntent1", with parameter 'value' of type @sys.number. Intent gets one number, stores it in the conversation context. It it doesn't have four numbers yet, it calls itself through followup("eventIntent1") to get another number.

Desired conversation:

assistant: "give me a number"
user: "1"
assistant: "give me a number"
user: "2"
assistant: "give me a number"
user: "3"
assistant: "give me a number"
user: "4"
assistant: "You gave me 1 2 3 4"

Actual conversation:

assistant: "give me a number"
user: "1"
assistant: "give me a number"
user: "2"
assistant: "give me a number"
user: "3"
assistant: "Sorry, I can't help"

Fix:

The fix was to setup another intent called "intent2" triggered by an event "eventIntent2". The slot filling for them is identical (the logic above), except intent1 calls "eventIntent2" for a followup, while "intent2" calls "eventIntent1" for a followup. This tricks it into not having the same intent called times in a row. It allowed me to record an unlimited number of values.