Re-try an HTTP module if bundles returned = 0 after a few minutes
What is the problem & what have you tried?
I am trying to figure out a way to activate the error path if no bundles are returned for an HTTP module. The API call itself works very consistently, but the system itself is slow to update and frequently enough the call will be made but return nothing. In those cases, I would like to implement a “Retry” handler after a few minutes, but since it is not technically an error I cannot do this. (95% of the time the data that is being called IS there, but when new data is made it sometimes takes minutes for it to update and I don’t want to base my scenario timings around this 5% snag.) Any ideas?
add a router after the module with two routes with filters on them. One route for when the module returns the proper data and one to act as an error handler when the data is missing.
For example a sleep module and then the same module again to retry getting the data.
It really depends on expected behaviour- do you want to retry within one run OR treat the run as failed and call a subscenario/ mark this run as failed?
In the first scenario- you can go with the option suggested by @Stoyan_Vatov.
The tricky part - we don’t know what your workflow looks like after the HTTP module - if it is complex - I strongly suggest using the “magic router formula” where you save the HTTP output as a variable and fetch it on the 3rd route:
With this approach you can simplify the whole workflow as you will only manage one branch of modules after HTTP call. It is much more scalable solution. Without it you must have two sets of the same modules after HTTP call.
There is also a 3rd approach- you can call a subscenario which will be responsible only for the HTTP call - if >= 1 bundle, you will return output as a webhook response with 200 status. If < 1 bundle, you will return an error code and use, for example, a BREAK error handler in the main scenario.
How about changing the schedule only if you need to retry?
If no data is found, you automatically set the schedule to X minutes (whatever suits your use case). Then, Make will execute the scenario once every X minutes, until some data is found, when it will restore the original schedule. Like this:
This only adds at most 2 operations for every run.
The HTTP calls to set the schedule are calls to Make’s API. You need to setup an API Key with scenarios:read to get the current scenario scheduling and scenarios:write to make the API calls that (re)set the schedule. These calls only need to send a PATCHrequest to https://us2.make.com/api/v2/scenarios/{{var.scenario.id}} with the following payload:
In this case, it updates the interval to 1 minute.
Check your make region and call the appropriate URL (eg: https://us1.make.com). Set your scenario ID manually if your plan does not allow access to that variable.
It’s a hack to “emulate” a retry mechanism.
Either that or you use a Repeater module to restart the flow N times and check if the request has any results. But I found that this tends to consume more operations and does not garantee the execution.
What is your goal?
What is the problem & what have you tried?
