I’ve had a few stories break silently and I only noticed when something downstream went wrong. I’m wondering what the right approach is for building in proper error handling. Do people use specific patterns for catching failures, sending alerts, or retrying actions? Any advice on making stories more resilient would be really helpful.
We can do a lot of things in our story to handle potential errors depending on the error type, but there is always a chance there was some corner case that we didnt think about when we were building the story so the first thing I can recommend is using the “Notify when any action fails” setting on the story.
This will allow you to either send email or webhook notification when any action fails in the story. This does not handle the error, but it will notify you able them so you can build in handling.
(You can point this towards a Tines webhook and build a little notification story to alert you, or create cases or any other way you want handle, log or notify errors in your story)
With this part covered lets talk about errors, and how to handle them.
In general there tends to 3 different kind of errors logged.
- HTTP request error: When a HTTP request actions returns a error code.
- Formula errors: Your Tines formula threw an error because of invalid input or incomplete formulas or anything like that.
- Anything and everything else.
So lets take them one at a time
HTTP Request Error:
HTTP Request errors are not an error thrown by Tines, but an error returned from the API endpoint you are reaching out to.
In these cases I always recommend looking up the error codes whatever message they contains.
Errors like 400, 401, 403, are usually around authentication and permission issues so you may not want to handle them automatically as they will often require troubleshooting why.
(This is why notifications are always good!)
404 can be a little special as “Not Found” can some times be expected and not really considered an error. (Like some APIs if you search for a something that does not exist it will return a 404)
In this case you can add the “Log error on Status” setting to your HTTP Request action, and exclude 404, from the ranges or error codes
This way 404 will not be considered an error by Tines on this action.
Another way to handle HTTP request errors is to retry the request, (this is especially useful for 5XX error types as they are usually temporary errors on the remote endpoint.
The best option here is to use the Retry on status setting, and configure what status you want it to retry on.
When doing this I also recommend adding the “Retries” setting (by default Tines will retry 25 times, with a longer and longer wait between each retry, and all 25 retries will take around 3 hours 30min, before the last retry have completed and the action will finally throw an error. So keep this in mind when you set the number of reties. (usually recommend stating at 5 and see how it goes if you need more retries)
The last kind of HTTP Request error that takes a little handling is status code 0
This status code usually means Tines had an issue with the request.
Most common reasons for a status code 0 is: Timeout
This error indicates the remote endpoint took longer than the timeout of the HTTP request action.
Most times this can be handled by Increasing the Timeout setting in the action (Tines default is 30 seconds), I recommend increasing to 60, and see if that help, and if not maybe go to 90 if there is still errors. (max is 5 min, but realistically if an endpoint takes more than 2 min to respond there may be something wrong on that endpoint and I recommend looking into it on that side)
Other status 0, errors are things like network issue, or issues resolving the domain and so on. (usually the best approch is troubleshooting these on a case by case basis)