I’ve noticed that my Validate Payload Node that validates payload received after HTTP request with a schema creates a error in a workflow: **FlowTimeoutError** Timeout running workflow
I am wondering what could cause it since I am providing Schema and Path for Errors… Schema seems to be matching payloads. At least with online checkers I used. I remember last time it was an issue with an “error” word in a payload name. FYI, I have “error” again in my payload names. Could it be the reason? Should I rename my payload paths?
Thank you for follow-up edits. It looks better now. May I ask why HTTP node is causing a workflow error? I use a timeout value and a error path. Should’t workflow just continue with a error message written to an error path? The thing is I am using Losant API node to set-up a disconnection status for the device if HTTP request fails. Because of this error my device is always shows as connected even it does not respond… Please advise
I would like to ask if there are any updates on the workflow error. It seems as some sort of bug to me. Could you confirm it? I think the workflow should not stop even if the link is offline. Just in case, my HTTP node settings are like that:
I just chatted with our Engineering Team, and I have an answer for you
You are correct. “Store HTTP Error at Payload Path” is working. This is why you see the NodeTimeoutError in your error path. This means that your HTTP request within the HTTP Node timed out. The limit is 30 seconds.
But! The after the HTTP Node ( looks like somewhere within the Validate Payload Node), your Workflow timed out.
Here, you see two back to back errors, not one. In this case, it looks like your HTTP Node (30-second limit) took too long, then your Workflow (60-second limit )didn’t have enough time to run after that.
Ways to fix:
Set a smaller timeout on your HTTP Node(s).
Break up your Workflow into smaller workflows.
You can do also Workflow to Workflow communication using the Workflow Trigger Node. (Workflow to Workflow does count against your payload limit)
Thank you for the detailed review of my request. You are right. Basically, I needed to run three HTTP requests in a row within a workflow’s loop in order to form an update of one device (this is defined by the device’s API). Every my HTTP node had a timeout of 30 seconds. So once the device was not available - the duration of the workflow string was exceeding 60 seconds at the end.
I have decreased the timeouts of every HTTP node and re-arranged logic triggering Losant API (Connection Status) node.
I think it would be good to add a workflow 60 sec timeout reminder somewhere in the platform. For some reason, I was missing this piece of information
A follow up question in this topic.
I just realized that 60 seconds timeout for the workflow limits one of the data acquisition algorithms I put in place. Basically, I try to read data from N devices inside of a loop node by using HTTP Node. Let’s assume 5 first devices are not responding and the accumulated timeout of those first 5 devices (5 devices*15 seconds = longer than a workflow timeout) will break the workflow and it will prevent other N-5 being read. Is there any way to avoid these congestion? I can see an option to trigger an external workflow for the poll of each device. Is it a good option? If yes, is there a way to pass fully a payload from the parent workflow to the child workflow using Workflow Trigger node/Workflow Payload String Template, so I can just easily copy the logic without correcting variable paths in a newly created child workflow?
