Gestion des Erreurs et Tentatives Répétées

A. Aperçu

Le pipeline de téléchargement et de traitement vidéo est conçu pour être robuste et résilient. À chaque étape — du téléchargement du fichier à l’analyse finale de la vidéo — le système anticipe les échecs potentiels. La gestion des erreurs est intégrée à plusieurs niveaux, et des nouvelles tentatives automatiques sont mises en œuvre là où cela est approprié. Cela garantit que les erreurs temporaires n’interrompent pas l’expérience utilisateur et que tous les échecs sont enregistrés à des fins de diagnostic.

B. Catégories d’erreurs

1. Erreurs côté client (HTTP 4xx)

• 400 Mauvaise requête :

  • Se produit lorsque le client envoie des données mal formées (par exemple, champs requis manquants comme video ou user_id, ou format de fichier invalide).

  • Erreurs de validation sur les champs d’entrée (par exemple, type de fichier incorrect ou format de timestamp invalide).

• 401 Non autorisé :

  • Déclenché lorsque le jeton d’accès est manquant ou invalide.

• 403 Interdit :

  • Retourné lorsqu’un utilisateur manque des permissions nécessaires (par exemple, un non-administrateur essayant de créer une session au nom d’un autre utilisateur).

• 404 Non trouvé :

  • Se produit si la ressource demandée (comme une session spécifique ou un fichier vidéo) n’est pas disponible.

• 422 Entité non traitable :

  • Utilisé lorsque le type de fichier est correct mais ne peut pas être traité (par exemple, corruption du fichier vidéo, échecs de chiffrement/déchiffrement).

2. Erreurs côté serveur (HTTP 5xx)

• 500 Erreur interne du serveur :

  • Capture les problèmes inattendus pendant le traitement backend, tels que des exceptions non gérées dans les modules de traitement vidéo.

• 503 Service indisponible :

  • Indique une indisponibilité temporaire du service, potentiellement due à une charge élevée ou à une maintenance.

C. Stratégie de nouvelle tentative

1. Mécanisme de nouvelle tentative automatique

Pour les erreurs transitoires — en particulier les problèmes de réseau ou une surcharge temporaire du backend — le système met en œuvre une stratégie de nouvelle tentative avec recul exponentiel :

• Déclencheurs de nouvelle tentative :

  • Délais d’expiration réseau, réinitialisations de connexion, erreurs HTTP 503, ou erreurs 500 indiquant un problème temporaire.

• Politique de nouvelle tentative :

  • Le client (ou le service de traitement lui-même) relancera automatiquement l’opération échouée jusqu’à un maximum de 3 à 5 fois.

  • Les délais entre les tentatives augmenteront de manière exponentielle (par exemple, 1 seconde, 2 secondes, 4 secondes) pour éviter de surcharger le backend.

• Disjoncteur :

  • Si un point de terminaison échoue constamment au-delà du nombre maximum de tentatives, le système “ouvrira” un disjoncteur pour arrêter temporairement les nouvelles tentatives, enregistrer l’erreur et alerter le système de surveillance.

2. Intervention manuelle et solutions de secours

• Solutions de secours :

  • Dans les cas où un fichier vidéo ne peut pas être traité après toutes les tentatives, le système peut se rabattre sur un message d’erreur générique (avec une option pour relancer le téléchargement manuellement) et stocker les détails de l’échec pour le support.

• Retour utilisateur :

  • L’API renvoie des messages d’erreur clairs et des codes d’erreur que le front-end peut utiliser pour informer les utilisateurs (par exemple, « Échec du téléchargement dû à des problèmes de réseau. Veuillez réessayer plus tard. »).

• Journalisation et alertes :

  • Toutes les erreurs — y compris celles qui déclenchent des nouvelles tentatives — sont enregistrées avec des détails (message d’erreur, horodatage, ressource affectée). Ces informations sont utilisées pour le débogage et peuvent déclencher des alertes pour les problèmes critiques.

D. Détails de mise en œuvre

• Format de réponse d’erreur : Chaque réponse d’erreur inclut une structure JSON cohérente :

{
  "error": "Detailed error message describing what went wrong.",
  "error_code": "SPECIFIC_ERROR_CODE"
}

• Mappage des codes de statut : Chaque point de terminaison dans l’API a été configuré pour renvoyer des codes de statut HTTP spécifiques pour les scénarios d’erreur attendus.

• Surveillance et analyse : Notre backend surveille en continu les taux d’erreur et les tentatives de relance pour ajuster automatiquement les seuils et informer les équipes d’ingénierie des problèmes potentiels.