[✅ Solution] Automation Error Handling

🙏 Ask the Community
1

Hi all,
How are errors handled when an automation is executing? What happens if it fails?

Are there any fallbacks automatically in place?

Is there any automatic retry into every step? And for the whole workflow? How deep can we conditionally set rules to tweak this behaviour (if tweakable)?

Thanks. Gary.

2 Likes
2

Hi @Super_Gary,

warm welcome to the Tape community from my side :blue_heart:

Thanks for reaching out. Indeed, there are several important details about errors in automations:

  • If an action fails, the workflow will stop at that point and be marked as “Failed”
  • For each action block, you can indeed override this behaviour by setting the “Continue on error” toggle. In that case, the workflow automation will proceed with the following actions instead of stopping, and will also be marked as “Completed” in the end. Note that this may lead to invisible errors, so use it wisely.
  • Once you leverage the “Continue on error” toggle, a token with the Most recent error will become available, that will contain a “best effort” parsed error message from that most recent error. It can be used for conditional checks or even retries
  • What we usually do if we need retries: Use the “Continue on error” for the sensitive action, e.g. a call to an external API that fails regularly. Then, check whether it was an error from their side, and call the automation itself again using the call automation action. This allows for a recursive call - just be careful with loops (they will create load and lead to your organisation being throttled)
  • Based on your conditions you can also end a run with success or failure state using the end run action

So, as you can see there is lots of options and also possibilities to tweak behaviour. Let me know if you have specific questions here or a concrete use case that you wish to implement. The community will assist you gladly in solving your case asap.

Cheers
Tim

3

Hi @Tim,
Thanks for your warm welcome and fast answer here.

Some more questions have now arisen regarding your answer.

  • Can we “collect” these errors (kind of build a log) so they do not become invisible? I mean all besides Most recent error.

  • Do we have to set all these call automation actions to retry on errors or is there any setting or toggle we can configure to have this behaviour as the default one?

  • In order to limit the recursive calls loops (although not sure what you mean with “be careful with loops”) can we set a maximum of retries and a timeout or minimum time to wait between retries?

  • What do you mean with “throttled”? Do you limit performance or the use of automations somehow?

Thanks. Gary.

1 Like
4

Hi @Super_Gary,

thanks for adding those additional questions. Let’s go through them one by one.

  • Can we “collect” these errors (kind of build a log) so they do not become invisible? I mean all besides Most recent error.

As you have full access to the token during the workflow automation, one can easily write that error into a dedicated “Error Logs” app for example and create a record there that includes the error message and context, such as the name of the automation that ran into the error. I hope that makes sense.

  • Do we have to set all these call automation actions to retry on errors or is there any setting or toggle we can configure to have this behaviour as the default one?

Currently there is no way of setting this behavior to the default, it needs to be set for every individual action. While this is the dedicated and explicit way, I do see your point in for example defaulting to that behaviour for all actions of a workflow automation (i.e. have a an option for that in each workflow automation). If you miss that feature, feel free to add a feature request for that.

  • In order to limit the recursive calls loops (although not sure what you mean with “be careful with loops”) can we set a maximum of retries and a timeout or minimum time to wait between retries?

As you need to implement your retry logic on your own, you can do all of these things (delay, max number of retries etc). If you need more assistance on that reach out here in the community, and maybe it could also make sense to create a guide for this.

With my statement I could have been more precise. I was referring to “infinite loops” that can be easily built in such scenarios on accident.

  • What do you mean with “throttled”? Do you limit performance or the use of automations somehow?

If users produce excessive load, their organization will be throttled to avoid useless resource consumption and to protect the platform from slowdowns.

I hope that I was able to clarify some of your questions. Thanks for sharing your concerns and for showing such deep interest in Tape.

Cheers
Tim