Les erreurs sont classées selon la cause et l'effet
Un délai d'attente réseau, une limite de débit, un jeton OAuth expiré, un média non valide et une recherche facultative vide nécessitent des réponses différentes. Un message commun « échec » n'est pas suffisant pour la réparation et la prise de décision de l'utilisateur.
En outre, il est évalué si le résultat est définitivement inconnu, manifestement non réalisé ou techniquement inutilisable. Cette distinction évite les actions externes en double.
- transitoire : réessayer peut être sûr
- auth : utilisateur ou reconnexion requis
- rate_limit : interruption et tentative ultérieure
- media_invalid : Ajuster l'élément
- optionnel_missing : ignorer la documentation
- unknown_external_state : vérifiez d'abord
La politique de récupération est corrigée avant l'erreur
Pour chaque action, il est défini à quelle fréquence elle peut être répétée, quelles erreurs peuvent être réessayées, si un changement de fournisseur est autorisé et quel est le plafond de coût applicable. Cela signifie que le système ne décide pas spontanément de nouveaux risques en cas d’état d’urgence.
Une solution de repli doit être techniquement équivalente et approuvée. Une recherche de stock peut passer d'une source à une autre lorsque la licence, la provenance et la pertinence sont vérifiées. Une publication ne peut pas être exécutée silencieusement via un autre compte ou canal.
Un seul canal cassé reste isolé
Un travail multicanal est constitué de contributions indépendantes avec des précurseurs communs. Si X refuse une autorisation, Instagram et Pinterest peuvent toujours être prêts. L'état global devient alors PARTIEL ou DÉGRADÉ au lieu de SUCCÈS ou d'ÉCHEC complet.
Les erreurs de sécurité courantes sont différentes. Un espace de travail incorrect, un manque d'approbation globale ou une limite de crédit dépassée arrête toutes les étapes dépendantes.
Les réparations doivent donc rester visibles
L'achèvement compte séparément les réussites normales, les étapes réparées automatiquement, les sauts facultatifs et les bloqueurs. Pour chaque réparation, la première erreur, la stratégie utilisée et le résultat final restent traçables.
Cette transparence présente des avantages pratiques : si les solutions de repli s'accumulent chez un fournisseur, il s'agit d'un problème opérationnel. Si la musique facultative est régulièrement ignorée, le flux de travail devrait peut-être être programmé sans musique par défaut.
Tester spécifiquement les défauts connus
L’auto-guérison ne peut pas être prouvée uniquement par des tests de chemin heureux. Une porte de production simule au moins les classes d'erreurs connues et vérifie si l'état, les coûts et les actions ultérieures sont corrects.
- 429 avec Réessayer-Après
- recherche de stock vide avec repli qualifié
- aucun morceau de musique facultatif approprié
- support obligatoire manquant pour une chaîne
- prestataire individuel dégradé
- Reconnexion OAuth requise
- statut de publication externe peu clair sans double tentative
FAQ
Un run réparé automatiquement est-il un SUCCÈS ?
Il peut être techniquement complété, mais doit montrer la réparation séparément. Un statut final neutre avec une reprise visible est plus honnête qu’un vert indifférencié.
Quand le recours à un fournisseur de secours est-il sûr ?
Si l'action est reproductible, le résultat externe n'est clairement pas réalisé, le remplacement est libéré et est techniquement et juridiquement qualifié.