Los errores se clasifican según causa y efecto.
Un tiempo de espera de red, un límite de velocidad, un token de OAuth vencido, un medio no válido y una búsqueda opcional vacía requieren respuestas diferentes. Un mensaje común de "fallo" no es suficiente para la reparación y la toma de decisiones del usuario.
Además, se evalúa si el resultado es definitivamente desconocido, claramente no realizado o técnicamente inutilizable. Esta distinción evita acciones externas duplicadas.
- transitorio: Reintentar puede ser seguro
- autenticación: usuario o reconexión requerida
- rate_limit: Retroceso y posterior intento
- media_invalid: Ajustar recurso
- opcional_missing: omitir documentado
- desconocido_externo_estado: verificar primero
La política de recuperación se corrige antes del error.
Para cada acción se define con qué frecuencia se puede repetir, qué errores se pueden reintentar, si se permite cambiar de proveedor y cuál es el límite superior de costes. Esto significa que el sistema no decide espontáneamente sobre nuevos riesgos en un estado de emergencia.
Un recurso alternativo debe ser técnicamente equivalente y estar aprobado. Se permite que una búsqueda de valores pase de una fuente a otra cuando se verifican la licencia, la procedencia y la relevancia. Una publicación no puede publicarse de forma silenciosa a través de otra cuenta o canal.
Un único canal roto permanece aislado
Un trabajo multicanal consiste en contribuciones independientes con precursores comunes. Si X niega el permiso, Instagram y Pinterest aún pueden estar listos. El estado general entonces pasa a ser PARCIAL o DEGRADADO en lugar de ÉXITO o FALLO completo.
Los errores de seguridad comunes son diferentes. Un espacio de trabajo incorrecto, una falta de aprobación general o un límite de crédito excedido detiene todos los pasos dependientes.
Como resultado, las reparaciones deben permanecer visibles.
La finalización cuenta por separado los éxitos normales, los pasos reparados automáticamente, los saltos opcionales y los bloqueadores. En cada reparación, se puede rastrear el primer error, la estrategia utilizada y el resultado final.
Esta transparencia tiene beneficios prácticos: si se acumulan reservas en un proveedor, se trata de un problema operativo. Si la música opcional se omite regularmente, quizás el flujo de trabajo debería programarse sin música de forma predeterminada.
Probar fallas conocidas específicamente
La autocuración no sólo puede demostrarse mediante pruebas del camino feliz. Una puerta de producción simula al menos las clases de error conocidas y comprueba si el estado, los costes y las acciones siguientes son correctos.
- 429 con reintento después
- búsqueda de stock vacío con respaldo calificado
- no hay pieza musical opcional adecuada
- falta medio obligatorio para un canal
- proveedor individual degradado
- Se requiere reconexión de OAuth
- estado de publicación externo poco claro sin doble intento
FAQ
¿Una ejecución de reparación automática es EXITOSA?
Técnicamente se puede completar, pero se debe mostrar la reparación por separado. Un estatus final neutral con recuperación visible es más honesto que un verde indiferenciado.
¿Cuándo es seguro recurrir a un proveedor?
Si la acción es repetible, el resultado externo claramente no se lleva a cabo, el sustituto queda liberado y queda técnica y jurídicamente calificado.