Infinite Loop Issue in Workflow with HTTP Request Action

Hi everyone, we have a workflow where one branch leaf node is a HTTP Request action but we noticed that the workflow keeps going on. This is a screenshot of the example, and I drew an arrow to what seems to be happening. It seems that when the HTTP Request (Action 5B) action is complete, any replies in the Slack thread triggers Action #3, then Action #4 (condition) then Action 5B (HTTP Request) which results in an infinite loop. Could we be doing something incorrectly with our setup? I've been trying to find an End action to stop Lindy from continuing but the documentation seems to be saying that the workflow ends when it hits a leaf node.

👀1

✅1

15 comments

Marvin A.
·
·
hey Kolton G. thx for sharing! this sounds very unusual. happy to look into this! can you share the task URL?
✅1
Marvin A.
·
·
How to share your Lindy task URL: 1. Click your Lindy agent → click “tasks” 2. Find the task you need help with 3. Click the specific task (you should see the full execution) 4. Copy that page URL from your browser 5. Paste the URL in your support request Note: The URL should include “conversationID” followed by a number 💡 Screenshots are also helpful!
Kolton G.
·
·
https://chat.lindy.ai/create-ltr-edits-67aa5c514b9f34b36ed2d3dc/tasks?conversationId=67ed7b1a8f52bae90c9a4032
Kolton G.
·
·
You'll see that after HTTP Request has been sent, it's grabbing in Slack replies in the thread which is odd since the flow should end.
Marvin A.
·
·
ahh I see what you mean
Marvin A.
·
·
so what you can do here is add a “Delete Current Task” step to the right side
Marvin A.
·
·
the problem is that the Send Message on the left will listen to replies and enter the condition state again as soon as one arrives
Marvin A.
·
·
lmk if this is helpful!
Kolton G.
·
·
Ahh, I see, so the Send Message action on the left will trigger even though in this "state machine" we went right? Got it, so should I only need to add this Delete Current Task when using Conditions like this I assume?
Marvin A.
·
·
exactly - since that “After reply received” state is active - it will continue listening → triggering your condition
Kolton G.
·
·
Thank you Marvin A., so should I look at this flow chart less like a "state machine" since I was thinking that the arrow flow (in the image) is kinda whats happening and that you cannot go back a step, so the left branch would be never be hit. If it's not a "state machine" how would Lindy determine which "After reply received" would be triggered given that there are two (Action #3 and Action #5A)?
lindy
·
·
hey, just popping in here! Kolton G. if i understand what youre wanting, i think the best solution here is to add a Observe Messages Slack action after the HTTPS request to ensure the agent stops responding on follow up replies from the original Send Channel Message
🙌1
lindy
·
·
this will end / stop the workflow once it hits that Observe Messages action and wont trigger any actions upon new replies
Kolton G.
·
·
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.
lindy
·
·
lindy — are you thinking that adding an Observe Message action right after the HTTP Request might help end the workflow cleanly?
yes. dont use Delete Task
👍1