According to the documentation, a flow’s timeout parameter is:
An optional number of seconds indicating a maximum runtime for the flow. If the flow exceeds this runtime, it will be marked as failed. Flow execution may continue until the next task is called.
Am I correct in my understanding that setting this parameter to 200 will not stop the flow after 200 seconds but will instead mark the flow as Failed once it will have finished?
In my case, I’ve set this value because I have a task that may be stuck in an infinite loop (receiving messages) and I want my flow to exit in such a case. For now, it doesn’t seem like the flows with tasks stuck in loops are stopping by themselves, and they are still marked as Running in the UI.
Is this behavior normal? If it is, what is the reasoning behind not enforcing the timeout? Also, is there a way to enforce it anyway?
Good Q, I’m not sure if we are able to directly cancel the remote execution of a flow run, I’ll check with the team
my understanding is, we can’t kill the actual process yet, but we may add that soon-ish thanks to this:
so the way you described that seems correct and we don’t kill the process yet, only stopping the flow run execution after 200s so that no new tasks get spun up
And stopping the flow run execution doesn’t have any effect on the UI? Shouldn’t there be an additional state to reflect this? For now, and if I am indeed in this case, the flow still appears Running without event a log reflecting that it exceeded the timeout.
Hi Anna! Did you still want a GitHub issue about this (killing flows when the timeout happens so they dont lurk in the background indefinitely), or is this part of the feature set now?