Módulo 6: Manejo de Errores

Patrones de Continue on Fail

Siguiente →

Descripción de la cápsula

Continue on Fail dice "si este nodo falla, sigue el workflow de todos modos". Es la herramienta para fallos parciales — cuando algunas operaciones del batch fallan pero quieres procesar las que funcionaron.

En esta cápsula vas a aprender los patterns típicos, cuándo usarlo, cómo manejar los items fallidos, y los riesgos de usarlo mal.

Lo que vas a aprender

  • ✅ Configurar Continue on Fail en nodos críticos
  • ✅ Procesar fallos vs ignorarlos
  • ✅ 3 patrones: best-effort, separate streams, eventual consistency
  • ✅ Reconocer cuándo NO usar Continue on Fail

El concepto

Sin Continue on Fail:

[A] → [B] → [C] → [D]

Si B falla, todo se detiene en B. C y D nunca ejecutan.

Con Continue on Fail en B:

[A] → [B con Continue] → [C] → [D]

Si B falla, output de B incluye error campo. C y D ejecutan con ese item (incluyendo el error).

Configuración

En el editor del nodo:

  • Settings → Continue On Fail: ON

Patrón 1: Best-effort processing

Procesas 100 items. Algunos pueden fallar. Quieres procesar todos los exitosos.

[Lista 100 items]
   │
[SplitInBatches]
   │
[HTTP API con Continue on Fail]
   │
[IF: $json.error existe?]
├─ TRUE → [log fallo en Sheet 'failed'] → continue loop
└─ FALSE → [procesar normal] → continue loop

Resultado: 95 procesados OK, 5 loggeados como fallos. Workflow termina sin error global.

Patrón 2: Separate streams

Después de Continue on Fail, separar items exitosos de fallidos para tratamiento distinto.

[Operación con Continue on Fail]
   │
[IF: $json.error?]
├─ TRUE → [stream de fallidos]
│         - Loggear
│         - Re-encolar para retry mañana
│         - Notificar si es alto volumen
│
└─ FALSE → [stream de exitosos]
           - Procesar normal
           - Agregar al reporte

Útil cuando exitosos y fallidos requieren acciones distintas.

Patrón 3: Eventual consistency

Si una operación crítica falla, queremos retry más tarde sin detener el workflow ahora.

[Webhook: pedido entrante]
   │
[procesar pedido localmente] ← no falla
   │
[Sync a CRM con Continue on Fail]
   │
[IF: sync falló?]
├─ TRUE → [Sheet: append a 'pending_sync']
└─ FALSE → [Sheet: append a 'synced']

Otro workflow Schedule diario re-procesa pending_sync. Eventual consistency — el sistema termina sincronizado, aunque no en tiempo real.

Detectar el error en el item

Después de Continue on Fail, los items fallidos tienen un campo error:

{
  "error": {
    "message": "Connection timeout",
    "name": "TimeoutError",
    "description": "..."
  },
  "originalData": { ... }  // depende del nodo
}

Para detectar:

[IF: $json.error is not empty]
├─ TRUE → fallido
└─ FALSE → exitoso

O:

[IF: $json.error.message contains "timeout"]

Para clasificar por tipo de error.

Cuándo NO usar Continue on Fail

Si el fallo es bloqueante

Si no puedes continuar sin el resultado del nodo:

  • Validación crítica (no continuar sin validar)
  • Operación que produce input para el siguiente nodo

Sin Continue on Fail: workflow se detiene, error es visible. Con Continue on Fail: continúa con datos basura, problemas downstream.

Si los items fallidos causan side effects

Si tu siguiente nodo manda email "Procesado: {{ $json.result }}" y el resultado es error, el email es nonsense.

Cómo evitar: IF después que filtra items con error antes de procesar.

Si quieres falla loud

A veces quieres que el workflow falle visiblemente para notar el problema. Continue on Fail oculta los problemas.

Trampas comunes

Trampa 1: Continue on Fail oculta problemas serios

Qué pasa: Continue on Fail activo en un nodo crítico. Falla todos los días. Workflow termina con "success" cada vez. Pasa el tiempo, alguien nota que algo no funciona.

Cómo evitar:

  • Después de Continue on Fail, monitorear count de fallos
  • Si pct fallos > X, alertar
  • No "set and forget"

Trampa 2: Procesar items con error sin filtrar

Qué pasa: Continue on Fail produce items con error campo. Nodo siguiente los procesa como si fueran exitosos. Resultado: emails mandados con "Hola undefined", filas creadas con datos basura.

Cómo evitar: IF después que filtra items con error.

Trampa 3: Sin retry en items fallidos

Qué pasa: 5% de items fallan por errores transitorios. Continue on Fail los descarta. Cada día pierdes 5%.

Cómo evitar: Loggear fallidos en Sheet, otro workflow retry diario.

Trampa 4: Continue on Fail en workflows secuenciales críticos

Qué pasa: Workflow procesa pago → crea factura → manda email. Continue on Fail en "procesar pago". Si pago falla, workflow sigue, crea factura por pago no realizado, manda email diciendo "gracias por tu compra".

Cómo evitar: Continue on Fail solo en operaciones best-effort, no en cadenas críticas.

Continue on Fail vs Error Workflow

Estos no son sustitutos:

Continue on FailError Workflow
AcciónWorkflow sigue con error en itemOtro workflow se dispara
GranularityPer-nodoPer-workflow
CasoFallos parciales aceptablesFallo total inesperado
VisibleEn el output del nodoEn el Error Workflow

Usar ambos:

  • Continue on Fail para errores esperados (algunos items fallan)
  • Error Workflow para errores inesperados (todo el workflow falla)

Resumen

  • Continue on Fail: workflow sigue aunque nodo falle
  • 3 patterns: best-effort, separate streams, eventual consistency
  • Detectar fallos con $json.error
  • NO usar si: fallo bloqueante, side effects malos, quieres falla loud
  • 4 trampas: oculta problemas, procesar items con error, sin retry, en cadenas críticas
  • Complementa con Error Workflow (no es sustituto)

Lo que sigue: Error Workflow y Error Trigger profundizados.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorRetry Strategies ProfundizadasSiguiente →Error Workflow y Error Trigger