Retry

	Important
	This article describes alternatives and workarounds to mimic the Retry error handling directive.

Boost.space IntegratorPart of the Boost.space system, where you can create your connections and automate your processes. does not offer the Retry error handling directive. Two alternative solutions can be employed to mimic its functionality.

Using the Break directive

In the Advanced settings enable the “Allow storing of Incomplete Executions” option.
Attach an error handler route to the module.
Link the Break directive to the error handler route and configure it e.g. like this:

Drawbacks:

The minimum retry interval is one minute.
If the module is processing multiple bundles and the processing of a bundleA bundle is a chunk of data and the basic unit for use with modules. A bundle consists of items, similar to how a bag may contain separate, individual items. fails, the partial execution (only the bundle that caused the error) is moved to the incomplete executions folder and scheduled for retries according to the Break directive settings. However, the current execution continues and the module continues to process the subsequent bundles. At least you may enable the “Sequential processing” option in the ScenarioA specific connection between applications in which data can be transferred. Two types of scenarios: active/inactive. settings to prevent the scenario from executing again until the execution stored in the Incomplete executionsSometimes Boost.space Integrator cannot successfully finalize a scenario execution due to an error. Boost.space Integrator stores incomplete executions in a folder named Incomplete Executions. Each stored incomplete execution can be resolved either manually or automatically. folder has been successfully resolved.

Using the Repeater module

Employ the RepeaterA module that repeats tasks multiple times, often used for making repeated API calls, like uploading multiple items or processing lists. module and set its Repeats field to the maximum number of attempts.
Link the potentially failing module to the Repeater module.
Attach an error handler route to this module.
Link the Tools >Sleep module to the error handler route and set its Delay field to the number of seconds between the attempts.
Link the Ignore directive after the Tools > Sleep module.
Link the Tools > Set variable module after the potentially failing module and configure it to store the module’s result in a variable named e.g. Result.
Link the Array aggregatorWhen designing a scenario, use an array aggregator to merge multiple bundles into one single bundle. This may be necessary to format data properly for subsequent modules. The array aggregator also lets you define your target data structure. module after the Tools > Set variable and choose the Repeater module in its Source Module field.
Link the Tools > Get variable module to the ArrayWithin a bundle, data items of the same type are sometimes in an array. You can find an array by looking at the details of a bundle. Depending on the details of your scenario, you can map other modules to a specific item in an array or use iterators and aggregators to manipulate your data into other formats. When mapping,... aggregatorYou can use a table aggregator to create a table from multiple bundles. The table aggregator merges values based on your specified column and row parameters and outputs into a single bundle. One possible use is compiling blog posts or emails into a single email summary. module and configure it to obtain the value of the Result variable.
Insert the Tools > Get variable module between the Repeater module and the potentially failing module and configure it obtain the value of the Result variable.
Insert a filter between this Tools > Get variable module and the potentially failing module to continue only if the Result variable does not exist.

Here is a sample scenario where the HTTP > Make a request module represents the potentially failing module (you may create this scenario easily from the retry template.

	Note
Please note: If the result of the potentially failing module is too complex to be stored in a simple variable, you may employ data storeA data store is a built-in database in Boost.space Integrator. You can use data stores to store data from scenarios or transfer data between individual scenarios or scenario runs. Your account includes data stores, so you do not have to register at a third-party service. to store/retrieve the result. The Data store would contain just one record, the record’s key can be e.g. Result.

Note

Please note: If the result of the potentially failing module is too complex to be stored in a simple variable, you may employ to store/retrieve the result. The Data store would contain just one record, the record’s key can be e.g. Result.

Drawbacks:

This workaround might appear a bit too complex and it is also more demanding in terms of operationsOperations are tasks in integration scenarios, similar to "operations" in Make.com. Each action, like reading or updating a record, counts as one operation. They’re essential for data syncing between apps and reset monthly. Going over the limit pauses syncing until you add more or upgrade your plan..