Avis de fin de support : le 13 novembre 2025, le support d'Amazon Elastic Transcoder AWS sera interrompu. Après le 13 novembre 2025, vous ne pourrez plus accéder à la console Elastic Transcoder ni aux ressources Elastic Transcoder.

Pour plus d'informations sur la transition vers AWS Elemental MediaConvert, consultez ce billet de blog.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Gestion des erreurs dans Elastic Transcoder

Lorsque vous envoyez des demandes à l'API Elastic Transcoder et que vous obtenez des réponses depuis cette dernière, vous pouvez rencontrer deux types d'erreurs d'API :

Pour chaque erreur d'API, Elastic Transcoder renvoie les valeurs suivantes :

Pour obtenir la liste des codes d'erreur renvoyés par Elastic Transcoder pour les erreurs du client et du serveur, consultezCodes d'erreur d'API (erreurs de client et de serveur).

De plus, vous pouvez rencontrer des erreurs lors du traitement de votre tâche par Elastic Transcoder. Pour plus d'informations, veuillez consulter Erreurs de traitement de tâches.

Codes d'erreur d'API (erreurs de client et de serveur)

Les codes de statut HTTP indiquent si une opération a abouti ou non.

Le code de réponse 200 indique que l'opération a abouti. Les autres codes d'erreur indiquent une erreur de client (4xx) ou une erreur de serveur (5xx).

Le tableau suivant répertorie les erreurs renvoyées par Elastic Transcoder. Certaines erreurs sont résolues en réessayant simplement la même requête. Le tableau indique quelles erreurs sont susceptibles d'être résolues par des tentatives successives. Si la valeur de la colonne Réessayer est :

Pour plus d'informations sur le fait de réessayer des demaDemandesnsultez Nouvelles tentatives après erreur et interruptions exponentielles.

Exemple de réponse d'erreur

La réponse HTTP ci-dessous indique que la valeur pour inputBucket était null, ce qui n'est pas une valeur valide.

HTTP/1.1 400 Bad Request
x-amzn-RequestId: b0e91dc8-3807-11e2-83c6-5912bf8ad066
x-amzn-ErrorType: ValidationException
Content-Type: application/json
Content-Length: 124
Date: Mon, 26 Nov 2012 20:27:25 GMT

{"message":"1 validation error detected: Value null at 'inputBucket' failed to satisfy constraint: Member must not be null"}

Erreurs de traitement de tâches

Lorsqu'Elastic Transcoder rencontre une erreur lors du traitement de votre tâche, il la signale de deux manières :

Capture d'erreurs

Pour que votre application fonctionne correctement, vous devez intégrer une logique destinée à capturer les erreurs et à y répondre. Une approche standard consiste à implémenter votre requête au sein d'un bloc try ou d'une instruction if-then.

Les kits AWS SDK effectuent leurs propres tentatives et contrôles d'erreur. Si vous rencontrez une erreur en utilisant l'un des kits SDK AWS, vous devez voir le code d'erreur et la description. Vous devez également voir une valeur Request ID. LaRequest ID valeur peut aider à résoudre les problèmes liés à la prise en charge d'Elastic Transcoder.

L'exemple suivant utilise le kit AWS SDK pour Java pour supprimer un élément d'un bloc try et utilise un bloc catch pour répondre à l'erreur. Dans ce cas, il avertit que la demande a échoué. L'exemple utilise la classe AmazonServiceException pour extraire des informations concernant les erreurs d'opération, notamment Request ID. L'exemple utilise également la classe AmazonClientException au cas où la demande n'aboutirait pas pour d'autres raisons.

try {
   DeleteJobRequest request = new DeleteJobRequest(jobId);
   DeleteJobResult result = ET.deleteJob(request);
   System.out.println("Result: " + result);
   // Get error information from the service while trying to run the operation	
   }  catch (AmazonServiceException ase) {
      System.err.println("Failed to delete job " + jobId);
      // Get specific error information
      System.out.println("Error Message:    " + ase.getMessage());
      System.out.println("HTTP Status Code: " + ase.getStatusCode());
      System.out.println("AWS Error Code:   " + ase.getErrorCode());
      System.out.println("Error Type:       " + ase.getErrorType());
      System.out.println("Request ID:       " + ase.getRequestId());
   // Get information in case the operation is not successful for other reasons	
   }  catch (AmazonClientException ace) {
      System.out.println("Caught an AmazonClientException, which means"+
      " the client encountered " +
      "an internal error while trying to " +
      "communicate with Elastic Transcoder, " +
      "such as not being able to access the network.");
      System.out.println("Error Message: " + ace.getMessage());
   }

Nouvelles tentatives après erreur et interruptions exponentielles

Un grand nombre de composants d'un réseau, tels que serveurs DNS, commutateurs, équilibreurs de charge ou autres, peuvent générer des erreurs à n'importe quel moment de la vie d'une requête donnée.

La technique habituelle pour traiter ces réponses erronées dans un environnement réseau consiste à implémenter les nouvelles tentatives dans l'application cliente. Cette technique augmente la fiabilité de l'application et réduit les coûts de fonctionnement pour le développeur.

Chaque kit SDK AWS prenant en charge Elastic Transcoder implémente une logique de nouvelle tentative automatique. Le kit AWS SDK pour Java retente automatiquement les requêtes et vous pouvez configurer les paramètres de nouvelle tentative à l'aide de la classe ClientConfiguration. Par exemple, dans certains cas, tels qu'une page web effectuant une requête avec une latence minimale et sans nouvelles tentatives, vous pouvez désactiver la logique de nouvelle tentative. Utilisez la classe ClientConfiguration et affectez au paramètre maxErrorRetry la valeur 0 afin de désactiver les nouvelles tentatives.

Si vous n'utilisez pas un kit AWS SDK, vous devez retenter les demandes originales qui reçoivent les erreurs serveur (5xx). Cependant, les erreurs client (4xx, autres qu'une exception ThrottlingException ou ProvisionedThroughputExceededException) indiquent que vous avez besoin de réviser la demande elle-même pour résoudre le problème avant de recommencer.

En plus de nouvelles tentatives simples, nous recommandons d'utiliser un algorithme d'interruption exponentielle pour un meilleur contrôle de flux. L'idée sous-jacente consiste à utiliser des temps d'attente progressivement plus longs entre les tentatives en cas de réponses d'erreur consécutives. Par exemple, vous pouvez attendre 1 seconde avant la première nouvelle tentative, 4 secondes avant la deuxième, 16 secondes avant la troisième, etc. Toutefois, si la requête n'a pas réussi après une minute, le problème peut être lié à une limite stricte et non à la fréquence des requêtes. Par exemple, il est possible que vous ayez atteint le nombre maximal de pipelines autorisés. Définir le nombre maximal de nouvelles tentatives pour qu'elles s'arrêtent au bout d'une minute environ.

Le flux de travail suivant illustre la logique de nouvelle tentative. La logique du flux de travail détermine d'abord si l'erreur est une erreur serveur (5xx). Ensuite, si l'erreur est une erreur serveur, le code réessaie la demande originale.

currentRetry = 0
DO
  set retry to false

  execute Elastic Transcoder request

  IF Exception.errorCode = ProvisionedThroughputExceededException
    set retry to true
  ELSE IF Exception.httpStatusCode = 500
    set retry to true
  ELSE IF Exception.httpStatusCode = 400
    set retry to false 
    fix client error (4xx)

  IF retry = true  
    wait for (2^currentRetry * 50) milliseconds
    currentRetry = currentRetry + 1

WHILE (retry = true AND currentRetry < MaxNumberOfRetries)  // limit retries