Notifications
Clear all
Topic starter
Hi,
I'm new to callin.io and I've set up an advanced scenario where a user submits a web form. I retrieve the data from the webhook before performing various steps, including calling the OpenAI API.
Since the OpenAI API frequently gets saturated, I'd like to implement a retry mechanism. Specifically, I want it to try up to 3 times, and if it still fails, switch to the HTTP operator to send a message back to the user on the form page.
I'm having trouble understanding why the "increment" function doesn't work when I select "after one scenario run." It only functions correctly when I choose "Never," but then the value never resets to 0.
I had to enable "sequential processing" in the scenario options for the processing to complete successfully.
How would you approach this?
I based my setup on this post: If Break Error Module Ends, Continue with Another Module, Possible?
Thanks,
Tof
Image from my script:
Posted : 23/01/2024 3:23 pm
Hi
It's unfortunately not straightforward to define a secondary error route after 3 "Break" resolution attempts. As you pointed out, utilizing the "Increment function" isn't ideal because the counter cannot be reset.
You could, however, explore an alternative approach using Data Store modules.
Each time an error route is triggered, the datetime of the error is logged in the Data Store.
Immediately following this, the single oldest record would be retrieved (sorted in ascending order with a limit of 1). This effectively captures the very first instance of the error within a specific scenario execution.
The filters following the router then ascertain when the initial error occurred. If it's not older than a specified duration (e.g., 60 minutes), it implies that fewer than 2 or 3 Break attempts have been made, and consequently, "Break" will be activated.
If the error is older, it signifies that no further Break attempts are necessary, and a secondary route is then executed.
Finally, all error records are deleted at the conclusion of the secondary route, effectively resetting the Data Store for any subsequent error occurrences.
Kindly note that enabling "Sequential processing" is crucial for this logic to function correctly. Without it, multiple incomplete and standard scenario executions could occur simultaneously, disrupting the intended workflow. Additionally, a higher number of Break attempts should be configured for this logic to operate effectively. For instance, setting 6 attempts every 15 minutes means that if an error is older than 60 minutes, the Break module will not exceed 3 attempts.
I trust this explanation is clear.
Best regards,
Posted : 13/02/2024 11:54 am
You can chain two instances of the same module within the error route (ensure you add a sleep module to "space" them out).
Then, add a resume directive to the first two retries, followed by your "alternative" path/"operator" as desired.
This approach can be used to chain "fallback" modules in case one of the services is unavailable.
This method is likely simpler to implement as you are essentially cloning the original module.
(Resume directives do not utilize operations, whereas data stores do)
Posted : 13/02/2024 12:52 pm