A Make scenario stopped on one record: error handlers and incomplete executions explained

What happens when a module fails and nothing is set up

Make's overview says that with incomplete executions disabled, rollback is the default error handling if you set none. Rollback stops the run, reverts changes in modules that support transactions, and ends with an error status. The scenario is then deactivated after repeated failing runs; the page gives the default as three consecutive errors, and says a scenario triggered by a webhook is disabled immediately on an error. So one malformed record can stop everything behind it and then switch the scenario off.

The same page says some errors skip the consecutive-errors count: for an account validation error, an operations-limit error or a data-size error, Make disables the scenario's scheduling immediately. A handler on one module cannot repair a lost connection or an exhausted plan, and those need the account holder.

• Look at the scenario history for the failed run and read the error on the module that failed.
• Check how many failed runs came before it was deactivated.
• Check whether the scenario starts from a schedule or from a webhook, because the rules differ.

The five error handlers in plain words

Make's help centre lists five handlers that you attach to a module through an error route. Skip disregards the error and lets the scenario process later bundles. Retry stores an incomplete execution and enables automatic or manual retries. Resume sets a substitute value for the failed module and carries on. Commit stops the run and saves the changes already processed. Rollback stops the run and reverts them. Older material may use different names for some of these, so match the behaviour, not only the label.

An error route does not have to contain a handler, and Make says that if no module in the route outputs an error, it skips the error. That matters for alerts: a route that only holds a message module, such as a Slack message, tells you about the error but then ends without a directive, so by Make's own wording the error is skipped. Make says the Skip handler marks the run as successful, so run history may not show the error as a failure. Confirm what your route does with a deliberate failure on a copy, and end every error route with the directive you want.

• Skip: the bad record is dropped and the rest continue; the run counts as successful.
• Retry: the bad record is stored and can be retried or fixed; the rest of the bundles are processed.
• Resume: a stand-in value is used and the run carries on, so choose a value that cannot do harm.
• Commit and Rollback: stop the run, keeping or undoing the work done so far in modules that support it.
• A route with only a message module ends the error as a skip by Make's wording, so add the directive you mean and confirm it on a copy.

Incomplete executions: the part people miss

Incomplete executions are switched off by default. You turn them on with Store incomplete executions in the scenario settings. With them on, a failed run is stored in the Incomplete executions tab so a person can fix the data and resume it, and Make describes errors as turning into warnings. Stored runs can be fixed by hand or deleted, and the number you can hold is capped by your plan.

There is a trade-off, and it is larger than it first looks. Make's overview page says that when an error creates an incomplete execution, Make postpones the next scenario run until you resolve the stored execution, or until the Retry handler resolves it automatically. The scenario settings page describes the same hold under Process data in order. So a stored bad record can make the next scheduled run wait, not only the records behind it, and the wait ends when someone resolves the record or automatic retries succeed. That is the right behaviour when order matters, and a silent stall when nobody is watching. Pair a Retry-style route with an alert, name who resolves held records, and test a second scheduled run on a copy before you rely on it, because the effect on your own scenario is what counts.

• Decide whether order matters for this scenario before you choose the setting.
• Add an alert module on the error route, followed by the directive, so a stored record is noticed.
• On a copy fed by a disposable source, hold one record and then run again to see whether the next run waits.
• Remember that storing data counts against your plan's storage.

Choosing a handler for a record you cannot lose

If a record represents money, a customer or a legal notice, losing it quietly is worse than a pause. Holding it with an alert is the safer choice when a pause in later runs is acceptable, because a person can fix the record and resume. Skipping is reasonable only where dropping the record is acceptable and still reported. Resume with a substitute value is reasonable only where the substitute cannot create a wrong record downstream. Commit and Rollback matter when a module writes to an app that supports transactions; for apps without them, a partial write cannot be undone.

One setting rules out most of this. If Keep data confidential is on, Make does not keep the processed data, and its page warns that there are very limited options to solve errors. You cannot inspect or resume a record that was never kept.

What this guide does not cover

This guide does not repair a connection, restore an expired authorisation or buy more operations. Those belong to the account holder. It also does not move a scenario between platforms. The paid outcome for this problem is one scenario with one failing module: an error route with the directive you choose, an alert to a named person, and tests on a copy fed by a disposable source. It is accepted when the good records in a batch are written once, the bad one is held or skipped as agreed with its reason visible, the scenario stays scheduled, and a second run is tested and described, including whether a held record made it wait.