Find stuck flows

When you start to build complex flows that go beyond simple questions and answer, you may accidentally build in a stuck flow situation. This can happen when transitions leave a junction, script node, or other non-output node but cannot be traversed due to condition-restraints. In exercises such as how to branch at the beginning of a flow we advise setting up a fallback transition, in case none of the conditional transitions cannot be selected. We also describe in the troubleshooting page how to fix stuck flow errors when they occur in tryout. When a stuck flow is encountered, Teneo has to abandon the flow, meaning a correct answer cannot be given.

Stuck flows errors should never occur, so if they do, you will want to find and fix them ASAP. Using TQL it is easy to find stuck flow situations, delivering all the information needed to navigate to the flow location in Teneo, where you can analyze and repair it. In order to show what it looks like to find stuck flow errors using TQL we took the flow described in branch at the beginning of a flow and broke it. We added a condition to the fallback transition to make the response conditional on the mention of a city. So now if users ask generally about Longberry Baristas locations, the flow will generate a stuck flow error. That is what you will see in the examples shown below.

Let's first have a look at what happens inside the session logs when a stuck flow error occurs: stuck flow in session log

In the second event with index (6) we see a stuck flow is registered: stuck = true. The vertex ID in the previous event (5) is the last point in the flow that Teneo reached, before becoming stuck. It was not further to continue from that location. Knowing that this is what is logged, we can construct a query to show us the information we need, taking care to look at consecutive events within the same transaction.

This query gives you a report of all instances of stuck flows, one for each occurrence :

lu t.id as transactionId, t.e2.fname as stuckFlowName, t.e1.vid as stuckVertex:    
    t.e2.pathType == "drop-flow",   
    t.e2.stuck == "true" ,
    t.e1.eventIndex == t.e2.eventIndex - 1

This variation shows a streamlined list (without frequencies) where you can click into the offending flows and correct them:

lu t.e2.fname as stuckFlowName, t.e1.vid as stuckVertex:    
    t.e2.pathType == "drop-flow",   
    t.e2.stuck == "true" ,
    t.e1.eventIndex == t.e2.eventIndex - 1

The important part of the result is the vertex ID, a unique ID of the node at which the stuck flow error occurred. Here are the steps you can walk through to repair the errors you found:

  1. Click into the vertex ID shown in the TQL results.
    With our the locations flow that we broke we see the following results: stuck flow query results

  2. Examine the transitions leaving the node.
    Note that after clicking into the flow the location at which the flow became stuck is highlighted. stuck flow with highlighted vertex

  3. Make corrections and republish. In our case, it means changing the fallback condition to unconditional.

Was this page helpful?