Módulo 6: Manejo de Errores

Mini-Proyecto: Workflow Resiliente

Descripción de la cápsula

Cierre del módulo. Vas a tomar un workflow simple y convertirlo en resiliente aplicando todos los patrones de M06. Caso: workflow de procesamiento de orders que no puede fallar aunque servicios externos caigan.

Lo que vas a aprender

✅ Aplicar el checklist de diseño defensivo
✅ Implementar retry + fallback + Error Workflow en un workflow real
✅ Testear que la resilience funciona
✅ Documentar decisiones de diseño

El escenario

Workflow inicial (frágil)

[Webhook: nuevo order de Shopify]
   │
[Set: extraer campos]
   │
[HTTP: notificar a CRM]
   │
[Send Email: confirmación al cliente]
   │
[Slack: notificar equipo]

5 nodos lineales. Cualquier fallo en cualquier nodo → workflow se detiene → cliente recibe email o no, equipo se entera o no, CRM tiene el order o no. Estado inconsistente.

Workflow resiliente (objetivo)

Mismo flujo lógico pero con defensa en cada paso:

[Webhook con auth + validación]
   │
[Set: validar payload]
   │
[IF: válido]
├─ FALSE → log + skip
└─ TRUE → continuar
   │
[HTTP CRM con retry + Continue on Fail]
   │
[IF: CRM ok?]
├─ TRUE → log success
├─ FALSE (después retry) → Sheet 'crm_failures' + Slack alert + continuar
   │
[paralelo: Email + Slack]
   ├─→ [Send Email con Continue on Fail]
   ├─→ [Slack con Continue on Fail]
   │
[Sheet: log execution para tracking]

+ Error Workflow asignado para fallos catastróficos

Paso 1: Aplicar checklist defensivo

Pregunta	Plan
Trigger N veces (webhook duplicado)	Idempotencia: check order_id en Sheet 'orders_processed'
Validación	Set + IF: order_id, customer_email, total presentes
CRM API falla	Retry 3 + Continue on Fail + log a 'crm_failures'
Email falla	Continue on Fail + log a 'emails_failed'
Slack falla	Continue on Fail (notification is best-effort)
Volumen	Si > 50/min, alert
Errores totales	Error Workflow `[GUARDIAN]` asignado
Mantenimiento	Sticky notes con decisiones

Paso 2: Construir el workflow

2.1. Workflow

[PROY-G2M06] Process Order Resiliente

2.2. Webhook con auth

Webhook:
- Method: POST
- Path: /orders-webhook
- Authentication: Header Auth (X-Webhook-Secret)
- Response Mode: Immediately

2.3. Validación

[Set: validar]
- is_valid: {{
    !!$json.body.order_id &&
    !!$json.body.customer_email &&
    $json.body.customer_email.includes('@') &&
    !!$json.body.total
  }}
- invalid_reason: {{ ...lógica... }}

[IF: is_valid is true]
├─ TRUE → continuar
└─ FALSE → [Sheet: log 'invalid_orders'] → end

2.4. Idempotencia check

[Sheet: leer 'orders_processed']
   │
[IF: order_id NO en lista]
├─ TRUE → procesar (es nuevo)
└─ FALSE → [Sheet: log 'duplicates'] → end (ya procesado)

2.5. CRM call con resilience

[HTTP: CRM API]
- Retry On Fail: ON, 3 tries, exponential (1s, 2s, 4s)
- Continue On Fail: ON
   │
[IF: $json.error existe?]
├─ TRUE → [Sheet: append 'crm_failures' con todos los datos para retry manual]
│         [Slack: "CRM failed for order {order_id}, queued for retry"]
└─ FALSE → [log 'crm_success']

2.6. Email + Slack en paralelo

[Set: post-CRM]
   │
   ├─→ [Send Email con Continue on Fail]
   │    │
   │    [IF: error?]
   │    └─ TRUE → [Sheet: 'emails_failed']
   │
   └─→ [Slack con Continue on Fail]
        │
        [IF: error?]
        └─ TRUE → [Sheet: 'slack_failed']  // poco crítico

2.7. Log de execution

Después de todo:

[Set: status final]
- crm_ok: $json.crm_ok
- email_ok: $json.email_ok
- slack_ok: $json.slack_ok
- timestamp: $now

[Sheet append 'orders_processed']

2.8. Error Workflow

Asignar [GUARDIAN] como Error Workflow del workflow.

Paso 3: Sticky Notes

Documentar decisiones:

🛡️ DEFENSA:
- Idempotencia: check order_id antes de procesar
- Retry CRM: 3 con backoff (transitorios)
- Continue on Fail en Email/Slack (best-effort)
- Error Workflow [GUARDIAN] para fallos catastróficos
- Cola 'crm_failures' para retry manual diario

Paso 4: Test scenarios

Test cada escenario:

Test 1: Happy path

Manda webhook válido. Verifica:

Order en CRM ✓
Email recibido ✓
Slack mensaje ✓
Row en 'orders_processed' ✓

Test 2: Webhook duplicado

Manda el mismo order 2 veces. Verifica:

Primera ejecución procesa normal
Segunda: detecta duplicado → no procesa → log en 'duplicates'

Test 3: Webhook con datos inválidos

Manda sin email. Verifica:

Validación falla → log 'invalid_orders' → NO se procesa nada más

Test 4: CRM caído

Simula CRM caído (cambia URL a inválida). Verifica:

3 retries
Después fallo → log 'crm_failures' + Slack alert
Email y Slack siguen ejecutándose (Continue on Fail funcionó)

Test 5: Email caído

Cambia SMTP credential a inválida. Verifica:

Email falla
Slack y log de execution siguen
Sheet 'emails_failed' tiene el item

Test 6: Workflow falla catastrófico

Pon un nodo que siempre falla (HTTP a URL inválida sin Continue on Fail). Verifica:

Error Workflow [GUARDIAN] se dispara
Recibes Slack alert con detalles

Paso 5: Worker de cola de retry

(Workflow separado, no parte del principal)

[GUARDIAN] retry-crm-failures:
[Schedule cada 30 min]
   │
[Sheet: leer 'crm_failures' donde retry_count < 5]
   │
[SplitInBatches]
   │
[HTTP CRM retry]
   │
[IF: success?]
├─ TRUE → mover a 'orders_processed', remover de 'crm_failures'
└─ FALSE → incrementar retry_count en 'crm_failures'

Procesa fallos automáticamente. Eventual consistency.

Comparación: antes vs después

Aspecto	Workflow original	Workflow resiliente
Falla un nodo	Workflow se detiene	Continúa con error tracking
Webhook duplicado	Order duplicado en CRM	Detecta y skip
CRM caído	Workflow falla	Continue + queue para retry
Email falla	Workflow falla	Continue + log
Crítico que llega	Solo si todo está bien	Garantizado por design
Visibility de errores	Manual	Automatic alerts

Reflexión final

Lo que aplicaste

Pattern	Dónde
Validation at boundary	Set + IF al inicio
Idempotencia	Check de duplicados
Retry strategies	HTTP CRM con backoff
Continue on Fail	Email + Slack
Fallback paths	Cola de retry
Error Workflow	[GUARDIAN] asignado
Tracking	Sheet 'orders_processed'
Diseño defensivo	Checklist aplicado

Todo M06 en un solo workflow productivo.

Resumen y siguiente paso

Lo que construiste:

Workflow resiliente real production-ready
Maneja todos los modos de fallo gracefully
Sistema con eventual consistency para CRM

Lo que sabes:

Aplicar todo el toolkit de error handling
Diseñar defensivamente desde el inicio
Documentar decisiones

Antes de pasar a M07:

Workflow construido con todos los tests pasando
Confianza para hacer cualquier workflow resiliente
Hábito de aplicar checklist defensivo

Lo que sigue (M07 — Wait Nodes y Flujos Asíncronos):

Workflows que esperan — ya sea tiempo determinado, eventos externos, o aprobaciones humanas. Wait node más allá del Wait simple.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorDiseño Defensivo Siguiente →Introducción al Módulo: Wait Nodes y Flujos Asíncronos