How to Implement Automatic Retries using Zenaton

In computer software, failures happen all the time: databases fail, networks are unreliable, disk space and RAM are limited and third party APIs can become temporarily unavailable. These are just a few examples - basically almost anything can go wrong.

Well, sometimes it is not convenient enough. For example, you may have some tasks that are failing on a regular basis, possibly because you are using a third-party API that often have technical issues.

When you have such a task, it can become cumbersome to go to your dashboard every day, or even multiple times per day, just to check and hit the “retry all” button. That’s why one of the most requested features by our users is the ability to define retry policies that allow for automatically retries. We are working on this! But in the meantime, I’m going to show you a little hack to accomplish automatic retries by coding it directly into your workflow.

Being able to write workflows in code is one of the most interesting features of Zenaton, and our users sometimes don’t realize that. It allows you to do many powerful things and today we will implement an automatic retry of a task inside a workflow to demonstrate it. The workflow will be the following:

This gives us a total of 4 tries over a 10 minutes period, which should cover most of the short-time unavailability that could happen. The following code samples are written in PHP but this will work on every language supported by Zenaton.

Let’s start with the task! The trick is to make the task catch exceptions and errors that can happen and return them instead of throwing them. Throwing errors will interrupt the execution of code and be reported as an error on the dashboard, whereas if we return an exception, it will be like any other return value a task can return, and we will be able to make our workflow act differently based on this result. Also, if the task is still failing after all these automatic retries, we want it to throw and error so that it can be reported on the dashboard. Here is what it could look like:

The code is pretty straightforward. This task takes a bool parameter $throw that will determine, in case of an error, if the error is to be returned or thrown. The workflow will send the correct value for this parameter: as long as we want automatic retries to happen, the workflow will send the value false so that the task will return errors. When all automatic retries are complete, the value sent by the workflow will be true and allow the task to throw error, which will make it appear on your dashboard — where you can choose to manually retry the task.

Now let’s continue with the workflow code. The workflow will need to loop until the task returns a correct result or cycles through all of the automatic and the task is still failing. The workflow could look like this:

I have commented in the workflow so hopefully it is easy to understand.

And that’s all you need to have 3 automatic retries of this task, using a variable delay between them.

Let’s check the dashboard to monitor our results. If the task succeeded the first time, it looks like this:

If it’s succeeding after a few tries, it looks like this:

Finally, when the task fails four times in a row, it will look like this and give us the option to manually retry the task:

The behavior is exactly what we specified at the beginning of this article, and we were able to do that with only a few lines of code.

The monitoring feature is a great way to see what happened for a workflow. You can read more about it here.

Hopefully after seeing this you will be able to better appreciate why we built Zenaton workflows as code, and why we are convinced it is the right choice. It gives you a lot of power and versatility when using the platform. It allows for maximum flexibility, because most of the time, even if we don’t have a specific feature, you will be able to do it yourself using a little creativity and a few lines of code.

Although we were able to implement automatic retries using our ‘hack’, we believe that workflows should represent business logic and should not be cluttered with technical stuff. If you have a complex workflow, and you were to use this kind of code to handle technical failures, it would clutter the workflow and you would lose readability. So we are planning an elegant way of specifying automatic retries so that your workflows can stay focused only on the business case they are solving. Stay tuned!

Related posts:

With this project I wanted to emphasize and better understand how the object of a book often functions as a touchstone between the lives and consciousnesses of those who engage with it. However…

Millions of Americans and global citizens tuned in last night to view one of the most important speeches the Leader of the Free World will give in 2020, at least before his impeachment trial comes to…