LabEx
Rejoindre

Réessayer une étape échouée et gérer les erreurs permanentes

AWSBeginner
Pratiquer maintenant

Introduction

Une défaillance temporaire d'une dépendance peut disparaître, tandis qu'une commande invalide doit rester en échec. Vous configurerez des reprises sélectives et un chemin d'échec permanent, puis observerez les tentatives réelles et les résultats enregistrés.

Terminez d'abord Construire un workflow de commande en plusieurs étapes. Cette nouvelle VM fournit son propre traitement et des tables vides ; les machines, rôles et exécutions précédents ne sont pas réutilisés.

Lien avec les certifications

Ce laboratoire propose une pratique des sujets d’examen suivants.

Autoriser le workflow à appeler son traitement

Dans cette étape, examinez le traitement métier fourni et créez un rôle d'exécution distinct pour Step Functions.

Utilisez AWS View, à côté de Terminal, pour comparer les requêtes CLI aux ressources et résultats réels de ce lab. Préservez les données de référence fournies.

Cette nouvelle VM fournit une fonction de traitement et des tables indépendantes pour les commandes, le diagnostic et les références. Il n'existe encore aucune machine à états ni aucun rôle de workflow. Le traitement accepte une commande, enregistre sa quantité et son total, puis peut lire son récapitulatif. Pour tester des pannes artificielles, le mode flaky déclenche TransientOrderError à la première tentative, avant toute écriture métier ; le mode permanent déclenche InvalidOrder avant d'écrire. Les tentatives de diagnostic sont séparées des commandes métier. Le rôle d'exécution Lambda du traitement autorise déjà ces opérations sur les tables, qui ne font pas partie du travail à réaliser.

Commencez dans le répertoire du projet. Les affectations du shell enregistrent les identifiants renvoyés ; --query sélectionne un champ de la réponse et --output text produit une chaîne réutilisable.

cd /home/labex/project
WORKER_NAME=labex-ev04-worker
WORKER_ARN=$(aws lambda get-function-configuration \
  --function-name labex-ev04-worker \
  --query FunctionArn \
  --output text)
aws lambda get-function-configuration \
  --function-name labex-ev04-worker \
  --query '{Name:FunctionName,Role:Role,Runtime:Runtime,Timeout:Timeout}'
aws stepfunctions list-state-machines

Le traitement utilise Python3.12 et son propre rôle Lambda ; la liste des machines est vide. Step Functions a besoin de son propre rôle d'exécution. Une politique de confiance autorise le service Step Functions à assumer ce rôle ; une politique d'autorisations permet à la session obtenue d'appeler précisément ce traitement. Un here-document dont le délimiteur est entre guillemets écrit le JSON littéralement, et file:// le charge dans la requête.

cat > workflow-trust.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "states.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
JSON
ROLE_ARN=$(aws iam create-role \
  --role-name labex-ev04-workflow-role \
  --assume-role-policy-document file://workflow-trust.json \
  --query Role.Arn \
  --output text)

Écrivez un document d'autorisations ordinaire. Le shell insère $WORKER_ARN, limitant cette autorisation au traitement fourni.

cat > workflow-invoke.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "lambda:InvokeFunction",
      "Resource": "$WORKER_ARN"
    }
  ]
}
EOF
aws iam put-role-policy \
  --role-name labex-ev04-workflow-role \
  --policy-name InvokeWorker \
  --policy-document file://workflow-invoke.json
aws iam get-role-policy --role-name labex-ev04-workflow-role --policy-name InvokeWorker

La politique contient un seul ARN de fonction précis. Step Functions ne reçoit pas les autorisations DynamoDB du traitement : celui-ci effectue ces appels avec son rôle Lambda distinct. Lancez la vérification des autorisations.

Configurer des reprises limitées et un chemin d'échec permanent

Dans cette étape, construisez un workflow réel à deux tâches avec un comportement de reprise sélectif.

Reprise temporaire et échec permanent

L'erreur temporaire de ce traitement peut disparaître lors d'une nouvelle tentative. Son erreur permanente suit Catch jusqu'à un résultat explicitement en échec.

Dans ASL, Retry énumère les erreurs de tâche qui permettent une nouvelle tentative. ErrorEquals doit correspondre au type d'erreur de la fonction. IntervalSeconds:1 commence par une attente d'une seconde ; BackoffRate:2 multiplie l'attente suivante. MaxAttempts:2 permet jusqu'à deux reprises après la tentative initiale. Cette règle traite uniquement TransientOrderError, et non toutes les défaillances possibles.

Catch sélectionne un autre état pour une erreur dont la tâche n'a pas récupéré. ResultPath enregistre l'erreur sous failure ; Next mène à un état Fail explicite. Gérer une erreur ne signifie pas que le travail métier a réussi. Une erreur permanente InvalidOrder se termine avec le statut FAILED et OrderRejected, sans prétendre avoir terminé une commande.

Un here-document dont le délimiteur est entre guillemets écrit le JSON littéralement. L'état Choice existant rejette une quantité inférieure ou égale à zéro ; les deux états Task enregistrent la commande, puis lisent son récapitulatif. Payload.$ transmet l'entrée courante, ResultSelector conserve les données réellement renvoyées par la fonction, ResultPath les préserve sous saved et OutputPath renvoie le récapitulatif réel.

cat > workflow-template.json <<'JSON'
{
  "StartAt": "CheckQuantity",
  "States": {
    "CheckQuantity": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.quantity",
          "NumericGreaterThan": 0,
          "Next": "StoreOrder"
        }
      ],
      "Default": "Rejected"
    },
    "StoreOrder": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": {
        "FunctionName": "WORKER_NAME",
        "Payload.$": "$"
      },
      "ResultSelector": {
        "result.$": "$.Payload"
      },
      "ResultPath": "$.saved",
      "Retry": [
        {
          "ErrorEquals": [
            "TransientOrderError"
          ],
          "IntervalSeconds": 1,
          "BackoffRate": 2,
          "MaxAttempts": 2
        }
      ],
      "Catch": [
        {
          "ErrorEquals": [
            "InvalidOrder"
          ],
          "Next": "Rejected",
          "ResultPath": "$.failure"
        }
      ],
      "Next": "ReadSummary"
    },
    "ReadSummary": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": {
        "FunctionName": "WORKER_NAME",
        "Payload": {
          "stage": "summary",
          "id.$": "$.saved.result.id"
        }
      },
      "OutputPath": "$.Payload",
      "End": true
    },
    "Rejected": {
      "Type": "Fail",
      "Error": "OrderRejected",
      "Cause": "Order could not be completed"
    }
  }
}
JSON
jq --arg worker "$WORKER_NAME" '.States.StoreOrder.Parameters.FunctionName=$worker | .States.ReadSummary.Parameters.FunctionName=$worker' workflow-template.json > workflow.json
MACHINE_ARN=$(aws stepfunctions create-state-machine \
  --name labex-ev04-orders \
  --type STANDARD \
  --role-arn "$ROLE_ARN" \
  --definition file://workflow.json \
  --query stateMachineArn \
  --output text)
aws stepfunctions describe-state-machine \
  --state-machine-arn "$MACHINE_ARN" \
  --query '{Name:name,Definition:definition}'

La définition contient les blocs de reprise sélective et de capture d'erreur. AWS View affiche la même configuration ; il n'existe encore aucune exécution ni commande métier. Lancez la vérification de la définition de reprise.

Observer les résultats réels de Retry, Catch et des autorisations

Dans cette étape, exécutez un cas de défaillance temporaire, un cas de défaillance permanente et un appel refusé.

La première tentative flaky du traitement met à jour un compteur de diagnostic et déclenche une erreur avant d'écrire une commande. La tentative suivante peut réussir. Une boucle shell limitée lit le statut d'exécution toutes les deux secondes jusqu'à ce que l'exécution cesse d'être en cours ; $(...) capture la sortie et break quitte la boucle. Si l'exécution reste RUNNING après la boucle, examinez-la avant de poursuivre.

RETRY_ARN=$(aws stepfunctions start-execution \
  --state-machine-arn "$MACHINE_ARN" \
  --name retry-order \
  --input '{"id":"retry-order","quantity":2,"mode":"flaky"}' \
  --query executionArn \
  --output text)
for attempt in $(seq 1 60); do
  STATUS=$(aws stepfunctions describe-execution \
    --execution-arn "$RETRY_ARN" \
    --query status \
    --output text)
  if test "$STATUS" != RUNNING; then break; fi
  sleep 2
done
aws stepfunctions describe-execution \
  --execution-arn "$RETRY_ARN" \
  --query '{Status:status,Output:output}'
aws stepfunctions get-execution-history \
  --execution-arn "$RETRY_ARN" \
  --query 'events[?type==`TaskFailed` || type==`TaskSucceeded`].{Type:type,Error:taskFailedEventDetails.error}'
aws dynamodb get-item \
  --table-name labex-ev04-orders \
  --key '{"id":{"S":"retry-order"}}' \
  --query Item
aws dynamodb get-item \
  --table-name labex-ev04-attempts \
  --key '{"id":{"S":"retry-order"}}' \
  --query Item

Le statut final est SUCCEEDED avec un récapitulatif terminé, de quantité 2 et de total 600. L'historique contient un événement TaskFailed avec TransientOrderError, suivi de deux événements TaskSucceeded : l'enregistrement réussi et la lecture du récapitulatif. La commande native a une quantité de 2 et un total de 600, et le compteur de tentatives de diagnostic vaut 2. Le nombre de tentatives et le nombre d'écritures métier sont différents.

Utilisez maintenant le mode d'échec permanent du traitement :

PERMANENT_ARN=$(aws stepfunctions start-execution \
  --state-machine-arn "$MACHINE_ARN" \
  --name permanent-order \
  --input '{"id":"permanent-order","quantity":2,"mode":"permanent"}' \
  --query executionArn \
  --output text)
for attempt in $(seq 1 30); do
  STATUS=$(aws stepfunctions describe-execution \
    --execution-arn "$PERMANENT_ARN" \
    --query status \
    --output text)
  if test "$STATUS" != RUNNING; then break; fi
  sleep 2
done
aws stepfunctions describe-execution \
  --execution-arn "$PERMANENT_ARN" \
  --query '{Status:status,Error:error}'
aws stepfunctions get-execution-history \
  --execution-arn "$PERMANENT_ARN" \
  --query 'events[?type==`TaskFailed` || type==`FailStateEntered`].{Type:type,Error:taskFailedEventDetails.error,State:stateEnteredEventDetails.name}'
aws dynamodb get-item \
  --table-name labex-ev04-orders \
  --key '{"id":{"S":"permanent-order"}}' \
  --query Item

Un seul appel réel du traitement échoue avec InvalidOrder ; Catch atteint Rejected et l'exécution se termine avec FAILED et OrderRejected. La règle de reprise temporaire ne correspond pas à cette erreur permanente. Aucun élément métier permanent-order n'existe.

Enfin, retirez uniquement l'autorisation d'appel du workflow. Votre opérateur peut démarrer des exécutions, mais le rôle du workflow ne peut plus appeler le traitement :

aws iam delete-role-policy --role-name labex-ev04-workflow-role --policy-name InvokeWorker
DENIED_ARN=$(aws stepfunctions start-execution \
  --state-machine-arn "$MACHINE_ARN" \
  --name denied-order \
  --input '{"id":"denied-order","quantity":2,"mode":"flaky"}' \
  --query executionArn \
  --output text)
for attempt in $(seq 1 30); do
  STATUS=$(aws stepfunctions describe-execution \
    --execution-arn "$DENIED_ARN" \
    --query status \
    --output text)
  if test "$STATUS" != RUNNING; then break; fi
  sleep 2
done
aws stepfunctions describe-execution \
  --execution-arn "$DENIED_ARN" \
  --query '{Status:status,Error:error}'
aws dynamodb get-item \
  --table-name labex-ev04-orders \
  --key '{"id":{"S":"denied-order"}}' \
  --query Item
aws iam put-role-policy \
  --role-name labex-ev04-workflow-role \
  --policy-name InvokeWorker \
  --policy-document file://workflow-invoke.json

Cette exécution refusée échoue sans appeler le traitement ni créer de données de diagnostic ou métier. Réessayer l'erreur applicative indiquée ne répare pas une autorisation manquante. L'autorisation prévue est rétablie. AWS View affiche le récapitulatif de la reprise réussie et deux échecs à côté de l'unique commande.

L'exemple ci-dessous montre le récapitulatif réel de la reprise, l'échec permanent et l'exécution refusée à côté de la commande enregistrée.

AWS View affiche la reprise réussie et l'échec permanent réels

Lancez la vérification de la reprise réelle.

Supprimer les ressources du workflow et les résultats artificiels

Dans cette étape, supprimez votre machine terminée, le rôle du workflow, la commande et les journaux, tout en préservant les ressources fournies.

Les trois exécutions sont terminées. Supprimer la machine la retire de la liste des machines actives. Retirez la politique du rôle qui vous appartient avant de supprimer le rôle, puis retirez la commande artificielle et le groupe de journaux du traitement créés par votre exécution.

aws stepfunctions delete-state-machine --state-machine-arn "$MACHINE_ARN"
aws iam delete-role-policy --role-name labex-ev04-workflow-role --policy-name InvokeWorker
aws iam delete-role --role-name labex-ev04-workflow-role
aws dynamodb delete-item --table-name labex-ev04-orders --key '{"id":{"S":"retry-order"}}'
aws dynamodb delete-item \
  --table-name labex-ev04-attempts \
  --key '{"id":{"S":"retry-order"}}'
aws logs delete-log-group --log-group-name /aws/lambda/labex-ev04-worker

Consultez des inventaires obtenus avec succès pour prouver ce qui reste :

aws stepfunctions list-state-machines
aws iam list-roles --query 'Roles[].RoleName'
aws dynamodb scan --table-name labex-ev04-orders --query Items
aws logs describe-log-groups --query logGroups
aws dynamodb scan --table-name labex-ev04-reference --query Items

Il ne reste aucune machine active, commande ni groupe de journaux. Seul le rôle du traitement fourni subsiste, et l'élément de référence est inchangé. Conservez le traitement et les tables fournis : ils appartiennent aux ressources de préparation, distinctes du workflow et des ressources que vous avez créés. Les erreurs réseau ou d'authentification ne prouvent jamais une suppression.

Supprimez les fichiers ordinaires créés dans ce lab :

rm -f workflow-trust.json workflow-invoke.json workflow-template.json workflow.json

AWS View affiche des listes vides pour les machines, les exécutions et les commandes, ainsi que la référence préservée. Lancez la vérification du nettoyage avant de terminer la VM.

Résumé

Vous avez configuré des reprises limitées pour une défaillance temporaire précise et Catch vers un échec permanent explicite. L'historique natif et les commandes réelles ont distingué les tentatives des écritures métier ; le refus d'accès n'a produit aucun effet sur le traitement ou les données métier. Vous avez supprimé les ressources et résultats du workflow qui vous appartenaient, tout en préservant les ressources fournies.

L'unité suivante traite une défaillance qui survient après l'écriture métier, lorsque réessayer pourrait répéter son effet.

Connexe AWS Cours
Les bases d’AWS pour débutants

Les bases d’AWS pour débutants

aws
AWS S3 pour débutants

AWS S3 pour débutants

aws
AWS IAM pour débutants

AWS IAM pour débutants

aws