Debug post-mortem · 17 October 2026 · 8 min read

“It worked once”: why your n8n workflow returns 0 items on the second run

We hit this on our own product, in a clean test instance, before shipping it: run the flow, get three leads, run it again with the same input, get zero, and the chain stops dead. The culprit is not the AI, the pagination or the credentials. It is a feature of the deduplication node that most tutorials never mention.

The symptom, exactly as it appears

A prospecting flow: fetch businesses → normalise → remove duplicates by placeId → score with an LLM → filter. First execution: 3 items in, 3 items out, everything green. Second execution with the same response from the API:

04 - Eliminar duplicados (place_id)   →  0 items
05 - DeepSeek: puntuar y redactar      →  not executed
...
lastNodeExecuted: 04 - Eliminar duplicados (place_id)

No error, no red node, no stack trace. The execution is technically successful and the output is empty. If you are testing a template you just bought, this is the moment you conclude it is broken.

It is deterministic, and that is the clue

We ran it three times: 3 items, 0 items, 0 items. Identical input, identical result. A bug in a code node, a bad expression or a race condition would not be that polite. Deterministic zero on the second run means state: the node is remembering something the first run gave it.

The evidence: where the memory lives

n8n's own execution data was empty of answers — workflow_entity.staticData was {}. The state is not in the workflow entity, and it is not in the execution. It is in the instance database, in a table called processed_data, keyed by workflowId:

table: processed_data
{
  "mode": "entries",
  "data": ["ChIJ_syn_AAA1", "ChIJ_syn_AAA2", "ChIJ_syn_AAA3"]
}

Those are exactly the three placeIds from our mock. The node writes them on the first execution and, on the second, considers every incoming item already seen — correctly, from its own point of view.

Why this is a feature, not a bug

The operation is called Remove Items Seen in Previous Executions. In production that is precisely what a daily prospecting flow needs: without it you would push yesterday's fifty businesses into your CRM every morning at eight, and your sales team would start ignoring the sheet. The node is doing its job.

The problem is the documentation gap: the phrase “previous executions” is easy to read as “previous items in this batch”. They are two different operations inside the same node, and only one of them persists between runs.

Three ways out, in order of preference

1. Clear the history deliberately. RemoveDuplicates v2 exposes the operation clearDeduplicationHistory. Put it on a small manual-trigger branch (or run it once from the node's own operation list) when you want a clean slate: a demo, a new niche, a test with the same dataset.
2. Test with different data. If you are validating a template, vary the search term or the city on each run. The node is not the thing under test.
3. Make it explicit in the flow. Keep the dedupe node — it is the reason a daily run stays useful — and document next to it that its memory is per workflow and lives in the instance database. That one line saves the buyer an afternoon.

Do not “fix” it by switching to Remove Items Repeated Within Current Input unless you actually want duplicates across days. You will trade an afternoon of confusion for a CRM full of repeats.

The generalisable lesson

Any node that can hold state between executions deserves a line in your troubleshooting notes. In n8n that family includes deduplication memory, the Wait node's form responses, and anything written to the filesystem. When a workflow behaves differently on the second run, the first question is not “what did the model do”, it is “what did the previous execution leave behind”.

We shipped the fix and the note inside the product: our troubleshooting document, section 12, describes this case with the remedy, and the test report records the three executions. A template that hides this is not more robust — it is a refund waiting for a Tuesday.

Quick checklist for the “works once” class of bugs

1. Re-run with the same input and count items at each node. Find the node where the count drops to 0.
2. Look for state: dedupe memory, static data, files written by a previous run, a cache key.
3. Check the instance database (processed_data for dedupe), not only the execution view.
4. Fix by clearing state explicitly, not by removing the node that provides the useful behaviour.
5. Write it down next to the node. The next person to hit it will be you.

Related: the five stages of the pipeline · the scoring rubric · all articles