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

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.

Step Functions coordonne les tâches Lambda ; le worker fourni enregistre les commandes dans DynamoDB et lit leurs récapitulatifs. L’accès CLI est déjà configuré ; aucun compte AWS personnel ni clé d’accès n’est nécessaire.

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

Vue d’ensemble du laboratoire

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 en haut 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

Enregistrez la valeur renvoyée dans WORKER_ARN :

WORKER_ARN=$(aws lambda get-function-configuration \
  --function-name labex-ev04-worker \
  --query FunctionArn \
  --output text)
echo "$WORKER_ARN"

Consultez le rôle et la configuration d’environnement de la fonction :

aws lambda get-function-configuration \
  --function-name labex-ev04-worker \
  --query '{Name:FunctionName,Role:Role,Runtime:Runtime,Timeout:Timeout}'

Consultez les machines à états restantes :

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

Enregistrez la valeur renvoyée dans ROLE_ARN :

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)
echo "$ROLE_ARN"

É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

Appliquez la politique d’autorisations du rôle de l’application :

aws iam put-role-policy \
  --role-name labex-ev04-workflow-role \
  --policy-name InvokeWorker \
  --policy-document file://workflow-invoke.json

Consultez la politique d’autorisations du rôle de l’application :

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.

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

Écrivez la configuration dans workflow.json :

jq --arg worker "$WORKER_NAME" '.States.StoreOrder.Parameters.FunctionName=$worker | .States.ReadSummary.Parameters.FunctionName=$worker' workflow-template.json > workflow.json

Enregistrez la valeur renvoyée dans MACHINE_ARN :

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)
echo "$MACHINE_ARN"

Consultez la définition et le rôle de la machine à états :

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.

Choisissez la correction selon le type d’erreur : une erreur temporaire du traitement peut justifier une nouvelle tentative, une erreur permanente de commande exige un échec explicite, et un refus d’invocation nécessite de restaurer l’autorisation ciblée. L’historique et les tables de commandes et de tentatives montrent si le traitement s’est exécuté et a écrit des données.

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)
echo "$RETRY_ARN"

Interrogez cette exécution jusqu’à ce qu’elle quitte l’état RUNNING :

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

Consultez l’état, la sortie et les erreurs de l’exécution :

aws stepfunctions describe-execution \
  --execution-arn "$RETRY_ARN" \
  --query '{Status:status,Output:output}'

Consultez l’historique réel d’exécution du flux :

aws stepfunctions get-execution-history \
  --execution-arn "$RETRY_ARN" \
  --query 'events[?type==`TaskFailed` || type==`TaskSucceeded`].{Type:type,Error:taskFailedEventDetails.error}'

Consultez l’élément réellement stocké dans la base de données :

aws dynamodb get-item \
  --table-name labex-ev04-orders \
  --key '{"id":{"S":"retry-order"}}' \
  --query Item

Consultez l’élément réellement stocké dans la base de données :

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)
echo "$PERMANENT_ARN"

Interrogez cette exécution jusqu’à ce qu’elle quitte l’état RUNNING :

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

Consultez l’état, la sortie et les erreurs de l’exécution :

aws stepfunctions describe-execution \
  --execution-arn "$PERMANENT_ARN" \
  --query '{Status:status,Error:error}'

Consultez l’historique réel d’exécution du flux :

aws stepfunctions get-execution-history \
  --execution-arn "$PERMANENT_ARN" \
  --query 'events[?type==`TaskFailed` || type==`FailStateEntered`].{Type:type,Error:taskFailedEventDetails.error,State:stateEnteredEventDetails.name}'

Consultez l’élément réellement stocké dans la base de données :

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

Enregistrez la valeur renvoyée dans DENIED_ARN :

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)
echo "$DENIED_ARN"

Interrogez cette exécution jusqu’à ce qu’elle quitte l’état RUNNING :

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

Consultez l’état, la sortie et les erreurs de l’exécution :

aws stepfunctions describe-execution \
  --execution-arn "$DENIED_ARN" \
  --query '{Status:status,Error:error}'

Consultez l’élément réellement stocké dans la base de données :

aws dynamodb get-item \
  --table-name labex-ev04-orders \
  --key '{"id":{"S":"denied-order"}}' \
  --query Item

Appliquez la politique d’autorisations du rôle de l’application :

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.

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"

Supprimez uniquement la politique d’autorisations du rôle de l’application :

aws iam delete-role-policy --role-name labex-ev04-workflow-role --policy-name InvokeWorker

Supprimez uniquement le rôle d’exécution du flux de l’exercice :

aws iam delete-role --role-name labex-ev04-workflow-role

Supprimez uniquement l’élément réellement stocké dans la base de données :

aws dynamodb delete-item --table-name labex-ev04-orders --key '{"id":{"S":"retry-order"}}'

Supprimez uniquement l’élément réellement stocké dans la base de données :

aws dynamodb delete-item \
  --table-name labex-ev04-attempts \
  --key '{"id":{"S":"retry-order"}}'

Supprimez uniquement le groupe de journaux de l’application indiqué :

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

Consultez les rôles IAM restants :

aws iam list-roles --query 'Roles[].RoleName'

Consultez les commandes réellement stockées :

aws dynamodb scan --table-name labex-ev04-orders --query Items

Consultez les groupes de journaux restants :

aws logs describe-log-groups --query logGroups

Consultez l’enregistrement de référence sans lien avec l’exercice :

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.

Pour approfondir ce sujet, consultez la documentation AWS : Retry, temporisation et gestion d’erreurs Catch.