https://discord.gg/botpress logo
Join Discord
Powered by
Timeout not actually timing out
# 🤝help
a
I've been working on trying out a Timeout workflow for our bot. The hope was to prompt the user that the chat is timing out, and give them the option to reply and continue the conversation or not. The prompt was using a raw input capture card with an AI transition to categorize the reply. If they want to continue, they are taken back to another workflow, otherwise the conversation ends. After building a simple workflow to test the functionality of this, I left the bot alone for a couple of days. I didn't realize (until I got the "message limit reached" email this morning) that the bot kept running for two days trying to time out but apparently never actually ending the conversation. I think I realize where I went wrong, in not actually connecting the prompt card directly to the end node in case the user never replies. However, I was curious after looking at the logs why the bot kept running, even after it says the conversation timed out due to inactivity. Any insight would be greatly appreciated!
b
were you testing using the emulator, or a published bot e.g. on your website or the shareable link?
a
It was published, testing via SMS as we've integrated with Twilio
b
gotcha
I see the nodes are transitioning to continue_conversation
what is giving you the sense that the conversation ended?
a
In the logs, after it says capture card received empty payload, the next message is "Conversation conv_01HPJ6M95CBHNMH3JAWFY12DPP timed out due to inactivity." And I didn't continue getting any messages.
b
also, just out of curiosity, what did you set the time out to?
a
because I was testing, I had it set to two minutes
After looking further back in the logs, I see now that "timed out due to inactivity" message is always sent before transitioning to the timeout workflow!
b
ah, I see what happened
take a look in the logs where your capture cards wait two minutes
for instance lines 389 to 390
and then 393 to 394
a
😬 I think I understand now
b
the timeout flow is triggered from the main flow when your user doesn't provide an input
then, in your timeout flow, you have a capture card
but there's nobody to provide that input
so every two minutes, your timeout flow is being triggered again
ad infinitum
😦
this is an interesting edge case - I see what happened but it would be nice if we could've prevented this
it might be possible to float a message or prevent this kind of infinite loop
a
Infinite loops, hate to see it. Thanks Robert, sometimes it seems so obvious after getting other eyes on it!
b
that's just how things go!
149 Views
PreviousNext
Powered by