https://discord.gg/botpress logo
Join Discord
Powered by
Long-running Actions
# 👀feature-requests
r
Just posting this question asked by @agreeable-caravan-87149 yesterday
@agreeable-caravan-87149 bot executions are limited to 60 seconds, so it's not possible to wait and poll inside an execute code card. At the moment, the only workaround possible is to use the Webhook integration to callback Botpress and resume the processing of the workflow, but this won't work well in all cases, as the 
event.conversationId
property will be missing and is mandatory to continue an existing workflow. -- There are a few potential solutions to this we could implement: 1) Provide a 
wait until
card that would execute a code bloc every X interval until the condition is reached. This means the workflow would receive an incoming event every X interval to execute the code and check if the task is done 2) We could improve the webhook integration to have an action that returns a webhook link that is bound to a specific 
conversationId
. You would call this action inside your workflow, and the output of the action would be a URL to continue the workflow execution. This would mean only 1 extra event you need to pay for, but your 3rd party system would need to call this API. Thoughts?
a
Thanks for stepping up, @rich-battery-69172 ! I ended up implementing the webhook workaround today successfully. Having said that, it is a challenging implementation as the webhook call starts a new session and I have to recover my workflow previous state before moving forward consistently. My 2 cents is that the #1 solution you proposed would be better from a state maintenance standpoint, as history would be kept. #2 would be technically more elegant, but the flows would be more confusing to be implemented.
r
@agreeable-caravan-87149 thanks for the reply! What if we could resume the workflow without the state complication? I think it would be fairly easy to do it without two workflows and states.
a
That definitely would help, @rich-battery-69172. Some additional considerations to this approach: - What happens when the external service returns a failure? - What happens when the external service doesn't return at all? - What happens when the user interacts while the long running external service is running? Could the webhook trigger be connected somehow to the flow (instead of being a start node), so you could control all of these aspects? You would avoid polling and keep the flow consistent on exceptions...
One thing I realized while trying workarounds to get a proper response for long running code in my bots: as of today, after the code runs for more than 60 seconds, it doesn't throw back a timeout exception, leaving the bot in an inconsistent state. It doesn't leave the current card, nor it moves to the error handling workflow. Treating this current behavior could be a first low hanging fruit implementation inside this topic.
2 Views
PreviousNext
Powered by