What is your goal?
The goal is simple: with Store incomplete executions and Process data in order both enabled, execution order should hold even when a module fails and the run is later resumed. What ran before the failure stays before it. What was still pending stays after — including bundles still queued from a module upstream of the failure.
- Router — the 1st route must finish before the 2nd starts.
- Iterator — if it emits three bundles and the 2nd fails, the 3rd must wait until the 2nd is resolved.
This isn’t an exotic requirement. Make’s own Converger workaround is built on it: an extra filter-free route holds the common sequence, earlier routes store their output with Set variable, and the common route reads it back. It only works if the earlier routes finish first.
The Iterator case is just as ordinary. A webhook delivers an order with three line items, an Iterator splits them, and each is written to an invoicing system that assigns sequential line numbers. The lines only come out right if the items are written in the order they arrived.
What is the problem & what have you tried?
Router. When a module in the 1st route fails and Store incomplete executions is enabled, the run does not stop. The 2nd route executes immediately and consumes its operation, while the rest of the 1st route is deferred into the incomplete execution and runs only on retry — manually or automatically — by which point the 2nd route has already committed. In the Converger case, the common route reads a variable the failed route never got to set.
Iterator. The 2nd bundle fails and is stored. The run continues and the 3rd bundle is processed straight away, leaving the 2nd to be finished later on retry. Bundles emitted in order are processed out of order. In the invoice example, item 3 takes line 2’s slot and item 2 lands at the end — the invoice no longer matches the order it came from.
In both cases a single run partially succeeds, in an order the scenario could never produce on a clean run. The reordering itself is never reported — the run ends with a warning about the original error, and the incomplete execution eventually reports as resolved.
The docs describe this, but not its consequence
- Overview of error handling — with Store incomplete executions on, a bundle erroring inside one route doesn’t stop the scenario. The error becomes a warning, the run continues, the bundle stops at the failing module in that route but is still pushed through all other matching routes.
- Manage incomplete executions — the resume is a fragment, not a replay. Retry starts “with the module that caused the error” using the original input.
However, neither mentions that the run might be reordered.
Same symptom reported in Jan 2025, never answered:
What should change
The stored incomplete execution should carry the entire remainder of the run — the failed module’s downstream path and the output still pending from upstream modules — rather than just the downstream fragment. A failure should halt the run and store it in full, rather than continuing to process pending output from an upstream Router, Iterator, or any other module. Resuming should then process everything that was left, in the order it would have run.
And this isn’t limited to the two setups above. Router and Iterator are only the most obvious cases. In fact, the problem arises whenever any module preceding the failed one still has unprocessed bundles — an Iterator, a Search or List module returning multiple results, or a Router pushing the same bundle through several routes. In all of these the scenario execution continues after the failure.