Cómo separar errores temporales y errores de datos
Clasifica los errores por la acción que puede resolverlos: esperar, corregir datos, recuperar autorización o investigar un resultado incierto.
Equipo enginerIT· 2 min de lectura
Clasifica los errores por la acción que puede resolverlos: esperar, corregir datos, recuperar autorización o investigar un resultado incierto. El código HTTP es una señal, no toda la decisión. Repetir una petición inválida sin cambiar nada solo añade ruido; cambiar sus datos automáticamente puede ocultar el problema original.
Clasifica por detalle y por acción de resolución
Guarda código HTTP, código funcional del proveedor, fase y referencia de petición. Consulta el catálogo de errores de la API utilizada. Un 400 suele orientar hacia una petición incorrecta, pero no diseñes toda la política con esa suposición: el proveedor puede distinguir conflictos o condiciones recuperables mediante códigos internos. Tampoco todos los 5xx significan que la escritura no ocurrió. En un timeout, la salida puede ser consultar el efecto.
Los fallos transitorios conocidos van a espera limitada; los datos inválidos vuelven al responsable del dato con campo y regla; los problemas de acceso se asignan a quien administra la integración. Un resultado ambiguo queda en conciliación. Evita mezclar estas colas bajo «fallidos». La guía Retry de Azure distingue cancelar y repetir según la naturaleza del fallo: tu clasificación debe permitir tomar esa decisión sin que el operador relea toda la traza.
No arregles el dato para hacer pasar la llamada
Si falta una unidad, no pongas cero; si el cliente no existe, no elijas el primero parecido. Conserva el original, explica el motivo y registra una corrección aprobada. Después decide si es la misma intención corregida o una versión nueva. Un error de permisos no se soluciona concediendo administración general: revisa identidad, recurso y alcance necesarios antes de ampliar acceso.
Valida la clasificación con ejemplos reales
Prepara casos de dato obligatorio ausente, límite de cuota, credencial inválida, servicio indisponible y respuesta perdida después de escribir. Compara salida esperada con salida obtenida y marca como desconocido lo que no puedas clasificar con evidencia. Un error nuevo necesita una ruta visible de investigación, no reintento infinito. Revisa recurrencia por campo y conector para corregir la causa. La clasificación funciona cuando la persona asignada sabe qué información necesita y qué condición permite devolver el trabajo al flujo.
Comprobaciones para cerrar la tarea
- ✓ Cada clase tiene una acción y un responsable.
- ✓ Un fallo desconocido no entra en reintento ilimitado.
- ✓ Los errores de datos conservan valor original y regla incumplida.
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.
Aplicarlo en tu empresa
Podemos revisar el entorno y acordar qué actuaciones, validaciones y mantenimiento necesitas.
Conocer el servicio relacionado →