Post-mortem · 17 de octubre de 2026 · 8 min de lectura

«Funcionó una vez»: por qué tu flujo de n8n devuelve 0 items en la segunda corrida

Nos pasó con nuestro propio producto, en una instancia de prueba limpia, antes de venderlo: corre el flujo, obtienes tres leads, lo corres otra vez con la misma entrada, obtienes cero, y la cadena se detiene en seco. El culpable no es la IA, ni la paginación, ni las credenciales. Es una función del nodo de deduplicación que casi ningún tutorial menciona.

El síntoma, tal cual se ve

Un flujo de prospección: buscar negocios → normalizar → eliminar duplicados por placeId → puntuar con un modelo → filtrar. Primera ejecución: 3 items entran, 3 salen, todo en verde. Segunda ejecución con la misma respuesta de la API:

04 - Eliminar duplicados (place_id)   →  0 items
05 - DeepSeek: puntuar y redactar      →  no se ejecutó
...
lastNodeExecuted: 04 - Eliminar duplicados (place_id)

Sin error, sin nodo rojo, sin stack trace. La ejecución es técnicamente exitosa y la salida está vacía. Si estás probando una plantilla que acabas de comprar, este es el momento en que concluyes que está rota.

Es determinista, y esa es la pista

Lo corrimos tres veces: 3 items, 0 items, 0 items. Entrada idéntica, resultado idéntico. Un bug en un nodo Code, una expresión mal escrita o una condición de carrera no serían tan educados. Un cero determinista en la segunda corrida significa estado: el nodo está recordando algo que le entregó la primera.

La evidencia: dónde vive esa memoria

Los datos de ejecución de n8n no tenían la respuesta: workflow_entity.staticData estaba en {}. El estado no está en la entidad del workflow ni en la ejecución. Está en la base de datos de la instancia, en una tabla llamada processed_data, indexada por workflowId:

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

Son exactamente los tres placeId de nuestro mock. El nodo los escribe en la primera ejecución y, en la segunda, considera que todo lo que llega ya fue visto —correctamente, desde su punto de vista.

Por qué esto es una función y no un bug

La operación se llama Remove Items Seen in Previous Executions. En producción eso es justo lo que necesita un flujo de prospección diario: sin eso, cada mañana a las ocho empujarías al CRM los cincuenta negocios de ayer y tu equipo comercial empezaría a ignorar la hoja.

El problema es el hueco en la documentación: «ejecuciones anteriores» se lee fácil como «items anteriores de este lote». Son dos operaciones distintas dentro del mismo nodo, y solo una de ellas persiste entre corridas.

Tres salidas, en orden de preferencia

1. Borrar el historial a propósito. RemoveDuplicates v2 expone la operación clearDeduplicationHistory. Ponla en una rama pequeña con trigger manual (o ejecútala una vez desde la lista de operaciones del propio nodo) cuando quieras partir de cero: una demo, un nicho nuevo, una prueba con el mismo dataset.
2. Probar con datos distintos. Si estás validando una plantilla, cambia el término de búsqueda o la ciudad en cada corrida. El nodo no es lo que estás probando.
3. Hacerlo explícito en el flujo. Conserva el nodo de deduplicación —es la razón por la que una corrida diaria sigue sirviendo— y documenta junto a él que su memoria es por workflow y vive en la base de datos de la instancia. Esa línea le ahorra al comprador una tarde entera.

No lo «arregles» cambiando a Remove Items Repeated Within Current Input a menos que de verdad quieras duplicados entre días. Vas a cambiar una tarde de confusión por un CRM lleno de repetidos.

La lección generalizable

Cualquier nodo que pueda guardar estado entre ejecuciones merece una línea en tus notas de diagnóstico. En n8n esa familia incluye la memoria de deduplicación, las respuestas de formulario del nodo Wait y todo lo que se escriba al sistema de archivos. Cuando un flujo se comporta distinto en la segunda corrida, la primera pregunta no es «qué hizo el modelo», es «qué dejó la ejecución anterior».

Publicamos el arreglo y la nota dentro del producto: nuestro documento de solución de errores, sección 12, describe este caso con su remedio, y el informe de pruebas registra las tres ejecuciones. Una plantilla que esconde esto no es más robusta: es un reembolso esperando al martes.

Lista rápida para los bugs de la familia «funciona una vez»

1. Vuelve a correr con la misma entrada y cuenta items nodo por nodo. Encuentra dónde cae a 0.
2. Busca estado: memoria de deduplicación, datos estáticos, archivos escritos por una corrida anterior, una clave de caché.
3. Revisa la base de datos de la instancia (processed_data para el dedupe), no solo la vista de ejecuciones.
4. Arregla borrando el estado explícitamente, no quitando el nodo que aporta la conducta útil.
5. Déjalo escrito junto al nodo. La próxima persona que lo pise vas a ser tú.

Relacionado: las cinco etapas del flujo · la rúbrica de puntaje · todos los artículos