Loops and Retries

Hey guys, How are u doing?

Suppose I have a workflow contains a loop. First time of execution, loop must run 400 times. But it raised an error in the 200th loop. So I retried it. (1. It continued after the 200th loop, right?)
Then it raised an error again in 300th loop. But I cannot retry the second execution. Only the original execution can be retried.
So the problem is: when I retry the original execution for the second time, it will continue from 200th loop not the 300th loop, right?

1 Like

Hi @jellybean,
I am not sure I understand you right.

Do you mean retry the execution from the execution list?

If you retry a failed execution, it will rerun the workflow from the beginning, not continue from where it failed. The two options

  • Retry with currently saved workflow
  • Retry with original workflow

are there because you could have changed your workflow since the execution failed. n8n will save the workflow if it fails so you can rexecute the original workflow even if you have changed it.

To simulate your loop error I created this workflow, that fails if counter=200 or counter=300. I also enabled Save manual executions for this workflow.

Everytime I execute this workflow and retry it from the executions list, the error message is:

So it does not continue your workflow after 200 if you retry it.

1 Like

Thanks marcus for your complete explanations. It helps a lot :slight_smile:

Hi jellybean,
I have some additional information. We do have the workflow setting Save Execution Progress:

I tried it out with my test workflow above. It becomes very slow and still fails on 200 on manual execution and retry. I did not try it in production or with queue mode enabled. Just wanted to let you know.

Thanks Marcus for the extra information.
Marcus I tested the workflow you’ve created, and I put a function node to log the counter. I found out when I retry the workflow, it continue from the point which has the error, Which is Throw Error node. that’s why it raises error again.

1 Like

Hi jellybean,
yeah that makes sense I guess. I was wondering if my test scenario makes sense :thinking:

If we retry with Save Execution Progress enabled, the last state saved when running into an error will be the successful execution 1 node before the failed node. On Retry it will always retry the failed node, in this case the throw error node. It cannot jump over the failed node because that would break your workflow.

Unless the error was due to somtehing like a http request temporary network error, it will always fail again.

1 Like

Exactly! I tested it with http request node with a local server as well and proved that idea.

1 Like