# Why does my Code node return only one item when the previous node outputs 200? **URL:** \ **Category:** Questions\ **Tags:** bug:unconfirmed\ **Created:** [October 10, 2026, 8:40pm UTC](https://community.n8n.io/t/why-does-my-code-node-return-only-one-item-when-the-previous-node-outputs-200/320469 "2026-10-10T20:40:35Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Amidu\_Louis](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/amidu_louis/32/62042_2.png) [@Amidu\_Louis](https://community.n8n.io/u/Amidu_Louis)\ **Post date:** [October 10, 2026, 8:40pm UTC](https://community.n8n.io/t/why-does-my-code-node-return-only-one-item-when-the-previous-node-outputs-200/320469/1 "2026-10-10T20:40:35Z")
I’m calling an external API using the HTTP Request node. The API sometimes takes a while to respond, so I enabled the retry option.The problem is that some requests end up creating duplicate records in the external system. ## Describe the problem/error/question From the execution history, it looks like the request gets retried even though the first request may have reached the API.is there a way to prevent this without disabling retries completely ## What is the error message (if any)? ## Please share your workflow ```auto (Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.) ``` ## Share the output returned by the last node ## Information on your n8n setup - **n8n version:1.123.x** - **Database (default: SQLite):** - **n8n EXECUTIONS\_PROCESS setting (default: own, main):** - **Running n8n via (Docker, npm, n8n cloud, desktop app):** - **Operating system:** ---
**Author:** ![Deepankar](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/deepankar/32/174793_2.png) [@Deepankar](https://community.n8n.io/u/Deepankar)\ **Post date:** [October 10, 2026, 9:09pm UTC](https://community.n8n.io/t/why-does-my-code-node-return-only-one-item-when-the-previous-node-outputs-200/320469/2 "2026-10-10T21:09:08Z")
Hey @Amidu_Louis Welcome in to the community and Yes, you can keep the retries. The duplicates come from how Retry On Fail works: it re-runs the whole node, not just the request that failed. The HTTP Request node sends every item it received, and if one of them errors the node fails and the retry sends all of them again, including the ones that already created their record. Put the HTTP Request inside a Loop Over Items with Batch Size 1, so each run of the node handles one item and a retry only resends that one. If the API supports an idempotency key (Stripe calls it the Idempotency-Key header), also send one that stays the same across retries, like an ID from your own data, so a request that timed out after reaching the API can’t create a second record either. Worth checking Options \> Timeout on the node too. Once you add that option it defaults to 10 seconds, so a slower response counts as a failure and gets retried. ---
**Author:** ![Mahdi\_Eqbal](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/mahdi_eqbal/32/188982_2.png) [@Mahdi\_Eqbal](https://community.n8n.io/u/Mahdi_Eqbal)\ **Post date:** [October 11, 2026, 3:44am UTC](https://community.n8n.io/t/why-does-my-code-node-return-only-one-item-when-the-previous-node-outputs-200/320469/3 "2026-10-11T03:44:15Z")
The one-item loop only helps if several input items are reaching the HTTP Request node and a retry is replaying successful siblings. It does not solve the timeout case in your question: the same request may already have created the record before the response was lost I would first check whether the destination accepts a stable idempotency key. If not, keep a business-derived operation reference and reconcile the destination before retrying an ambiguous result.a local “seen” flag alone cannot prove the remote write failed ---
**Author:** ![heroxcreed](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/heroxcreed/32/192765_2.png) [@heroxcreed](https://community.n8n.io/u/heroxcreed)\ **Post date:** [October 11, 2026, 5:33am UTC](https://community.n8n.io/t/why-does-my-code-node-return-only-one-item-when-the-previous-node-outputs-200/320469/4 "2026-10-11T05:33:18Z")
One thing to add to the Loop Over Items + idempotency suggestions: for a non-idempotent POST I would not use the HTTP Request node’s built-in Retry On Fail at all. It cannot tell a timeout (where the request may already have created the record) from a clean failure. Instead, set that node to On Error \> Continue (using error output) and build your own retry: if the status is 429, or it failed to connect before sending, Wait a few seconds and retry once or twice. If it timed out, first do a GET lookup using your own unique reference for that record, and only re-POST if it is not there. Treat a timeout as unknown, not as failed. Raising Options \> Timeout in the node helps, but it does not remove that ambiguity. ---
**Author:** ![Joy\_Ful](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/joy_ful/32/58894_2.png) [@Joy\_Ful](https://community.n8n.io/u/Joy_Ful)\ **Post date:** [October 12, 2026, 12:24am UTC](https://community.n8n.io/t/why-does-my-code-node-return-only-one-item-when-the-previous-node-outputs-200/320469/5 "2026-10-12T00:24:02Z")
Hi @Amidu_Louis , trust you’re well This can happen when the API processes the request but n8n doesn’t receive the response in time. The retry then sends the same request again.If the API supports idempotency keys, use a unique key for each operation so repeated requests don’t create duplicate records. If it doesn’t, you’ll need to check whether the record already exists before creating it Retries are useful, but for POST requests that create data, they aren’t always safe by themselves ---
**Author:** ![gabrielszegedi](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/gabrielszegedi/32/193351_2.png) [@gabrielszegedi](https://community.n8n.io/u/gabrielszegedi)\ **Post date:** [October 12, 2026, 6:54am UTC](https://community.n8n.io/t/why-does-my-code-node-return-only-one-item-when-the-previous-node-outputs-200/320469/6 "2026-10-12T06:54:25Z")
One addition to Deepankar’s answer: after raising the timeout, open one of the duplicated executions and look at the first attempt’s error. If it’s a timeout/ECONNABORTED rather than a 5xx, the request probably reached the API, and retrying it blindly will always risk a duplicate. In that case turn off Retry On Fail, set On Error to “Continue (using error output)”, and loop back only on errors where the request clearly never landed (429, ECONNREFUSED). Small tip: the title mentions the Code node, so editing it will help others find this. ---
**Author:** ![saim14](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/saim14/32/193113_2.png) [@saim14](https://community.n8n.io/u/saim14)\ **Post date:** [October 13, 2026, 5:40am UTC](https://community.n8n.io/t/why-does-my-code-node-return-only-one-item-when-the-previous-node-outputs-200/320469/7 "2026-10-13T05:40:05Z")
@Amidu_Louis, one edge case in the lookup-before-retry advice: an empty GET immediately after a timeout does not prove the original POST failed. The first write may still be processing, or the lookup may lag behind it. A second POST can then create a duplicate. A useful test in a sandbox/mock API: 1. Send operation `order-123` and delay its commit until after the client times out. 2. Make the immediate lookup return no record. 3. Retry while the first write is still pending. 4. Let both finish and count records for `order-123`. The acceptance check is one remote record, including across a restarted workflow. Where supported, persist and reuse the same idempotency key for that logical operation, within the provider’s documented retention window. A new key on retry defeats the protection. A server-enforced unique business reference/atomic upsert can also help if the API provides it. Without either guarantee, treat the timeout as an unknown outcome: reconcile with bounded waits, then route unresolved cases for review rather than blindly creating again. A longer timeout or Batch Size 1 reduces some failures but cannot guarantee a single remote write. ---
**Author:** ![Zara\_Fateh](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/zara_fateh/32/184656_2.png) [@Zara\_Fateh](https://community.n8n.io/u/Zara_Fateh)\ **Post date:** [October 13, 2026, 7:32am UTC](https://community.n8n.io/t/why-does-my-code-node-return-only-one-item-when-the-previous-node-outputs-200/320469/8 "2026-10-13T07:32:07Z")
Hi @Amidu_Louis, Zara here fron n8n support. welcome to the community! Building on what @Deepankar, @Mahdi_Eqbal and @heroxcreed already said: the duplicates happen because Retry On Fail can’t tell a timeout from a real failure. If the API created the record but the response arrived late, n8n sees an error and resends the same POST. Retry also re-runs the whole node, so if several items are going in and one fails, the ones that already succeeded get resent too. Putting the HTTP Request inside Loop Over Items with Batch Size 1 fixes the second case, but as Mahdi pointed out, it doesn’t help with timeouts. For those, the best fix is an idempotency key if the API supports one, using a value that stays the same across retries, like an ID from your own data (not a random value generated inside the node). If it doesn’t, follow heroxcreed’s approach: turn off built-in retry for that node, set On Error to Continue (using error output), and on a timeout do a GET lookup by your own unique reference before re-POSTing. Treat a timeout as “unknown,” not “failed.” Also check Options \> Timeout, since it defaults to 10 seconds once added, so a slow response can trigger a retry on its own. If you still face the issue or have any confusions then feel free to write to [help@n8n.io](mailto:help@n8n.io) and our team will make sure to assist you. ---
**Author:** ![akiraautomates](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/akiraautomates/32/193093_2.png) [@akiraautomates](https://community.n8n.io/u/akiraautomates)\ **Post date:** [October 14, 2026, 7:43pm UTC](https://community.n8n.io/t/why-does-my-code-node-return-only-one-item-when-the-previous-node-outputs-200/320469/9 "2026-10-14T19:43:00Z")
Building on the stable-reference and lookup-before-retry points above, here is one way to make that concrete when the API has no idempotency key, using a Data Table as a small ledger: 1. Give each item a stable `opRef` built from your own data (for example `{{ $json.orderId }}-create`). Don’t use `$now` or a random value, because it has to stay the same across re-runs. 2. Add a Data Table row `{opRef, status: "pending"}` _before_ the POST, then update it to `done` with the remote ID after a 2xx. 3. On the error output, any row still `pending` is “unknown”. Send it to your lookup/reconcile step instead of re-POSTing. 4. If the remote system has a free-text field (notes, metadata, an external ID), write `opRef` into it so the lookup in step 3 is an exact match. This also gives you an audit trail, since a duplicate shows up as two rows with the same opRef. (drafted with AI help, checked by me)