Qué comprobar al definir esperas exponenciales en una integración

Calcula la duración completa

Suma duración máxima de cada llamada, pausas y tiempo ya consumido en cola. Aclara si el número configurado significa intentos totales o reintentos después del primero. En un ejemplo hipotético, una tarea con plazo de diez minutos no puede reservar esos diez minutos solo para esperas y olvidar llamadas de un minuto. Define un máximo de pausa y una fecha límite absoluta para que el reinicio del trabajador no reinicie también el presupuesto.

Distribuye los intentos

Añade variación aleatoria cuando proceda para evitar que todos los trabajos fallen y vuelvan al mismo tiempo. Ese reparto no permite ignorar una espera mínima exigida por el servidor. Si la API devuelve instrucciones de espera, respétalas conforme a su documentación. Azure recomienda adaptar la estrategia al servicio y a la interacción: una pantalla que espera respuesta y una tarea nocturna pueden necesitar políticas diferentes aunque llamen al mismo recurso.

Comprueba las capas que ya repiten

Inventaría reintentos del SDK, conector, cola y flujo. Dos capas con varios intentos pueden multiplicar llamadas y duración sin que el operador lo vea. Elige un nivel con contexto suficiente para decidir y documenta qué hacen los demás. Revisa también el efecto de cancelar: dejar de esperar localmente no implica que la petición remota se haya detenido ni autoriza ejecutar una segunda escritura.

Prueba el calendario, no la fórmula

Inyecta un fallo temporal, un rechazo permanente y una interrupción que dure más que el plazo. Comprueba marcas temporales reales, número de llamadas y destino final de la tarea. Mantén la identidad de operación al repetir escrituras protegidas y deriva resultados ambiguos. Al agotarse el presupuesto, conserva el trabajo con motivo y responsable. Una prueba válida debe fallar si aparecen llamadas adicionales, si todas las tareas vuelven simultáneamente o si un error de datos entra en el bucle de espera.

Fuentes y documentación

• Azure Architecture Center: Retry — Distingue fallos transitorios, límites de intentos e impacto de políticas anidadas.
• Microsoft Graph: throttling — 429, Retry-After y errores individuales dentro de respuestas de lote.