Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 5 de 5
Concurrency y queueing
Retries corrigen fallos transitorios de una tarea; repair runs reejecutan el subconjunto fallido tras corregir la causa sin repetir trabajo exitoso.
17 min aprox.
05Decisión de diseñoConcurrency y queueing
Retries corrigen fallos transitorios de una tarea; repair runs reejecutan el subconjunto fallido tras corregir la causa sin repetir trabajo exitoso.
+
Concurrency y queueing
Retries corrigen fallos transitorios de una tarea; repair runs reejecutan el subconjunto fallido tras corregir la causa sin repetir trabajo exitoso.
Una retry policy limita intentos e intervalo y debe reservarse para fallos plausiblemente transitorios. Reintentar una violación de esquema determinista solo consume tiempo. Las tareas con efectos deben ser idempotentes porque tanto retry como repair pueden ejecutarlas de nuevo.
Un repair run mantiene el contexto del run original y permite reejecutar tareas fallidas o omitidas, con parámetros corregidos cuando corresponda. Antes de reparar se inspecciona error, input y versión; después se valida el resultado downstream. Una nueva ejecución completa es preferible si cambió el alcance o no puede garantizarse coherencia con tareas exitosas anteriores.
task_key: ingest_partner_api
max_retries: 3
min_retry_interval_millis: 60000
retry_on_timeout: true
timeout_seconds: 1800
python_wheel_task:
package_name: commerce
entry_point: ingest_partnerEl código debe escribir con una clave de petición o `MERGE`; tres reintentos de un append no idempotente pueden triplicar datos.
¿Por qué una tarea que soporta retries debe ser idempotente?
Profundiza
Un retry repite automáticamente una tarea ante un fallo que se presume transitorio; un repair run se inicia después para reejecutar tareas fallidas o omitidas y sus dependientes necesarios dentro de un run existente. Ninguno corrige lógica no idempotente. La política de retry especifica número, intervalo y, cuando aplica, backoff; debe ser corta para errores de red o capacidad recuperables y evitar tormentas sobre un servicio caído. Un error de schema, permiso o calidad determinista no mejora al repetir y consume tiempo de RTO. Repair conserva el contexto y parámetros del run original, por lo que es preferible a lanzar manualmente otro Job que pueda usar otra fecha. Antes de reparar se corrige la causa, se entiende qué outputs quedaron confirmados y se selecciona el mínimo subgrafo seguro. La publicación y los efectos externos necesitan claves que toleren repetición.
Nuevo intento automático de la misma tarea y contexto después de un fallo, sujeto a límites e intervalos configurados.
Recupera errores transitorios sin intervención, pero exige idempotencia y clasificación para no repetir fallos deterministas.Reanudación explícita de un run existente que reejecuta el subconjunto fallido o dependiente conservando su contexto original.
Reduce trabajo duplicado y mantiene la fecha y parámetros lógicos después de corregir una causa.Estrategia que aumenta el intervalo entre intentos, normalmente con aleatoriedad, para reducir presión sobre una dependencia degradada.
Evita tormentas coordinadas de reintentos y mejora probabilidad de recuperación de servicios con throttling.Resumen
Puntos clave
- Retry es automática y cercana al fallo; repair es una decisión sobre una ejecución existente.
- No todos los errores son transitorios ni deben reintentarse.
- Idempotencia permite reejecutar una tarea sin duplicar o retroceder estado.
Evita
- Configurar retries ilimitados para un error de datos permanente y ocultar el incidente.
- Reparar downstream con parámetros distintos sin verificar que los outputs upstream exitosos siguen siendo compatibles.