Tanto @kjooleng como @ClearStack acertaron de lleno respecto al crash OOM y el peligro de envíos de correo duplicados.
Cuando procesas 1000 elementos en una única ejecución lineal o bucle, Node.js acumula todos los estados de entrada/salida del nodo en memoria. El Garbage Collection no puede limpiar objetos hasta que se complete toda la ejecución del flujo de trabajo padre, lo que provoca terminaciones OOM en el host.
Aquí está el patrón de producción de 3 pasos para resolver tanto la fuga de memoria como el riesgo de correos duplicados:
### 1. El Patrón de Agrupamiento por Subflujos (Resuelve OOM)
En lugar de ejecutar los 1000 clientes potenciales en un único bucle en el flujo de trabajo padre:
1. Usa un **Nodo Split In Batches** (tamaño de lote: 50-100 elementos).
2. Pasa cada lote a un flujo de trabajo secundario usando el **Nodo Execute Workflow**.
3. **Por qué funciona:** Cuando cada ejecución de subflujo termina, n8n inmediatamente vacía su huella de RAM y activa el Garbage Collector de Node.js, manteniendo el uso de memoria plano durante una ejecución de 6 horas.
### 2. Verificación de Idempotencia (Previene Spam de Correos Duplicados)
Como señaló @ClearStack, si la ejecución #1 falla en el cliente potencial 260 y reinicia, los clientes potenciales 1-260 reciben correo electrónico dos veces.
* Dentro de tu subflujo, justo antes del Nodo Email Send, añade un **Nodo If / Filter** que verifique `already_contacted === true` (o consulte tu BD para `email_sent_at IS NOT NULL`).
* Si `true` → Omitir.
* Si `false` → Envía correo electrónico e inmediatamente actualiza el estado de la BD a `contacted`.
### 3. Aumenta el Límite de Heap de Node.js (Si es Autohospedado / Docker)
Si estás autohospedando n8n mediante Docker o PM2, el límite de memoria de heap de Node.js por defecto es alrededor de 2GB. Para trabajos por lotes de larga duración, aumentalo en tus variables de entorno:
```bash
NODE_OPTIONS=“–max-old-space-size=4096”
```
*(Esto asigna hasta 4GB de RAM al proceso n8n).*
Combinar **Subflujos + Agrupamiento + Verificaciones de Idempotencia Previa al Envío** es la forma estándar de ejecutar canalizaciones de 10k+ clientes potenciales sin bloquear n8n o enviar spam a usuarios.