Built-in task retry
Muhsin Hamzah
Often, a task fails for some unknown reason (particularly those from integrations) and a simple retry does the trick. However, building a retry loop into every task is quite a hassle and with crate workflows, it means un-syncing or having to use a wrapper workflow and retry the entire crate workflow.
Having a built-in task/action retry parameter would help a lot.
Log In
Chris Williamson
The way I would like to see this implemented:
Advanced tab -> "Retry on Failure" section with two fields: "Maximum retry count", and "Retry condition" (accepts a Jinja statement which will only retry if true e.g. {{ RESULT.response.statuscode == 429 }} or whatever). Maybe a third field for "Retry delay" if you're feeling really fancy.
Jack Musick
I'm currently doing this with a workflow that has inputs for max_retries, delay_in_seconds and parent_execution_id. It basically caches the retry state for the execution ID in table storage and throws a jinja error once there are too many retries.
It's not terrible, but this is definitely the kind of thing that should be built-in on the advanced tab with a condtion, especially for custom integrations.
Tim Fournet
Currently the platform does retry actions when we get failures like 429s, however that isn't surfaced to the workflow logs. We have tickets to make this visible and adjust retry parameters. Stay tuned!
Al Robison
Yes please!!
Ninja fails a lot. See it occasionally with Connectwise and others. Especially on bigger workflows this is can be a huge PITA. It would be amazing to have built-in retries in the actions.
Agreed with Richard - Wouldn't want infinite retries, but at least a couple would be great.
Richard Reiffer
This would be very helpful but we would want to be able to set a limit like 3 retries, then fails. This issue comes up a lot with HubSpot integration because of their restriction on how many API calls per minute we can do.