Thanks! That might be a better approach than using Delete Current Task, since we’ve noticed that doing so causes us to lose all the history.
We did try adding a Slack: Send Message action after the HTTP Request step, hoping it would terminate the workflow—but we still saw replies in that thread triggering jumps back to Action #3 or Action #5A, causing that infinite loop behavior we discovered.
lindy — are you thinking that adding an Observe Message action right after the HTTP Request might help end the workflow cleanly?
We’re planning to build more complex workflows, so I’d like to keep the team informed if Lindy’s workflow engine behaves more like a state machine—where you can only move forward to explicitly defined actions, and there’s no way to jump back to earlier actions unless there’s a pointer to them.
For example:
Action #1 → Action #2 → Action #3
In this model, there would be no way for Action #3 to loop back to Action #1 unless we explicitly define that path, and the workflow would simply end after Action #3.
