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.
Thank you all for the great suggestions! I think the solution from @mszymkowiak is the closest thing I can use. This is a rather complex scenario that pulls in quiz data from a course from our LMS (using REST), and my HTTP module uses a second API (GraphQL) our LMS has for different data (super cool having 2 different API’s for the same service!) The second API is rather finnicky and thus why it tends to take a while to update or be inconsistent.
Because of this, I can’t change the timing of the scenario because this is not the main function of it, just a small piece. I could set up a completely separate scenario that does this, then call that scenario from this one and set up a proper error handler on THAT; that might be the cleanest route to take. Ideally if that module returns nothing, I would be able to use make’s error handlers run it again after x time (perhaps by letting users define what an ‘error’ is) but thats beyond the scope of this question lol.
If the results of the 2nd API call are mandatory for the rest of the flow, then this solution is potentially ineffective, as you only get 1 retry after a fixed sleep time.
The best way to do it would be your own solution. In a sub scenario, make the http call, then add a router. If data is found, return it. If not, just force an error.
You can use something like parseNumber(NaN;0).
On the parent scenario, add a break directive and set the scenario to re-execute every n minutes.
What is your goal?
What is the problem & what have you tried?
