n8n Retry On Fail continue on error duplicate emails

Test record: read, not run. Fractional HQ read workflow-execute.js in n8n 2.38.1 on 29 October 2026. Not tested: the failing case, other n8n versions, a node with a single item, Stripe idempotency keys in n8n.

Symptom

We did not see this happen in a live run. We found it on 29 October 2026 while building a booking deposits template with a Gmail node that sends one email per client, and we wanted to know what Retry On Fail would do to it.

How to reproduce it

Set a Gmail node to send for several items, tick Retry On Fail, and set the node's error handling to continue on error. Then make the first item fail while the others would succeed. We have never watched that happen in a run, since all we did was read the n8n source.

Cause, as far as we know

We read workflow-execute.js in n8n 2.38.1. With continue on error, a retry fires only when the first output item carries json.error. When it fires, it reruns the entire node with every input item.

The consequences, as we read them, differ by position. If the first item fails, every other client's email is sent again. If the failure is on the second item or any later one, the retry never fires, because only the first output item is looked at.

The fix we applied

We keep retries for calls that are safe to repeat: reads, Sheets writes that are matched on a key, and Stripe calls made with idempotency keys. For anything that writes, sends or pays without such a key, we leave Retry On Fail off. For email specifically, we record the failure on the item's own row in the sheet, so someone can see which message did not go out and send it again deliberately.

A retry on a node with side effects has no way to tell which items already went out, so repeating the node repeats the side effect.

What we did not establish

We read the code in one version and did not run the failing case. We did not check other n8n versions, and we did not test a node with a single item, where the first-item rule would make the retry behave more sensibly. We have no record of how Retry On Fail behaves when continue on error is switched off, because that case was not the one we were checking. We also did not look at the Stripe idempotency-key behaviour ourselves; we are relying on the general rule that a keyed call can be repeated without charging twice, and we did not test it in n8n.

Written by Fractional HQ from its own runs. If your n8n behaves differently, email hello@fractionalhq.uk and we will correct the note.