Naveo

STEP 14 / 22

A5 TASK

TU PROMPT · 1 CASOS

Orbit te pide escribir una política de reintentos en forma de objeto JSON que describa qué tipos de fallo el sistema reintenta, cuántas veces, con qué backoff, y cuáles NUNCA se reintentan.

Tu sistema invoca tools que pueden fallar de cinco formas:

network_timeout (la conexión al proveedor expiró)
rate_limit_exceeded (el proveedor te limitó)
invalid_response_format (el modelo devolvió JSON malo)
unauthorized (auth falló)
business_validation_failed (ej: intentás cobrar a una tarjeta vencida)

Para cada uno, decidí si reintentar o no, cuántas veces, con qué backoff (constante, lineal, exponencial), y cuál es el dead-letter final si todos los reintentos fallan.

Formato esperado: JSON donde cada key es el código de error y el valor es {retry: boolean, max_attempts: int, backoff: "constant" | "linear" | "exponential", initial_delay_ms: int, dead_letter: string}.

305 chars

usa {{input}} donde vaya la entrada

RUBRIC · 1 CASOS · 6 CRITERIOS

"evaluación-meta"

CASO 1

MODO INVITADO

Estás viendo esta lección como invitado. Para guardar tu progreso, ganar XP y mantener tu racha, inicia sesión cuando estés listo para comprobar.

Cuesta 1 vida

No todos los errores se reintentan igual

Cuando un tool falla, tu agente tiene tres opciones: reintentar, escalar, o dead-letter. Elegir mal te lleva a uno de tres bugs clásicos:

Reintentás todo: amplificás un outage (todos los clientes martillando al proveedor caído), gastás presupuesto en errores garantizados, o duplicás operaciones (cobros, tickets, emails).
No reintentás nada: cada hiccup de red es un fallo visible. Tu sistema parece frágil cuando solo necesita un reintento.
Reintentás sin política: a veces 1 vez, a veces 10, a veces forever. Comportamiento impredecible, observabilidad imposible.

La solución: política explícita por tipo de error.

Las tres clases de error

Clase	Ejemplos	Retry
Transitorio	network timeout, 503, rate limit	SÍ, con backoff exponencial
Permanente	unauthorized, 404 not found, schema mismatch	NO. Escalar o dead-letter
Negocio	tarjeta vencida, inventario agotado, dato inválido	NO. Notificar al usuario

Backoff exponencial

La fórmula estándar: delay = initial_delay × 2^attempt + jitter.

Intento 1 falla → esperá 500ms.
Intento 2 falla → esperá 1000ms.
Intento 3 falla → esperá 2000ms.
Intento 4 falla → dead letter.

El jitter (random pequeño) evita el "thundering herd": si 1000 clientes fallan al mismo tiempo y todos reintentan exactamente a los 500ms, agravás el outage. Con jitter, los reintentos se desparraman.

Retry budget

Para sistemas grandes, agregás un presupuesto de reintentos por sesión: max 5 reintentos totales para toda la sesión del agente, no por error. Sin esto, una cascada de errores transitorios puede generar cientos de reintentos y consumir toda tu cuota.

Dead letter: el segundo paracaídas

Cuando los reintentos fallan, ¿qué pasa? Esa es la mitad de la política que la gente olvida:

queue_for_manual_review: el caso va a una cola que un humano revisa. Bueno para errores raros.
alert_oncall: notifica al oncall en tiempo real. Bueno para auth y permisos rotos.
notify_user: el usuario ve el error explícitamente y puede actuar. Bueno para negocio.
fail_visible: la operación falla y la traza queda en logs. Bueno cuando el sistema downstream maneja la recuperación.

Una política sin dead-letter es media política. Diseñá los dos lados: qué reintentás, y qué pasa cuando aún reintentando no se arregla.

Tu task

Escribí el JSON de política completo para los 5 códigos de error. El judge evalúa que cada uno tenga la estrategia correcta y un dead-letter accionable.