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 les flux de travail Step Functions Tous les états, à l'exception `Pass` des `Wait` états, peuvent rencontrer des erreurs d'exécution. Des erreurs peuvent survenir pour diverses raisons, notamment les suivantes : + **Problèmes de définition de la machine à états**, tels qu'un état Choice sans règle correspondante + **Défaillances de tâches**, telles qu'une exception dans une AWS Lambda fonction + **Problèmes transitoires,** tels que les événements liés à une partition réseau Lorsqu'un état signale une erreur, Step Functions échoue par défaut à l'exécution **complète** de la machine à états. Step Functions dispose également de fonctionnalités de gestion des erreurs plus avancées. Vous pouvez configurer votre machine à états pour détecter les erreurs, réessayer les états défaillants et implémenter des protocoles de gestion des erreurs avec élégance. Les capteurs Step Functions sont disponibles pour les états **Task**, **Parallel** et **Map**, mais pas pour les échecs d'exécution de machines à états de haut niveau. Pour gérer les exécutions susceptibles d'échouer, votre interlocuteur peut gérer l'erreur, ou vous pouvez imbriquer ces exécutions dans des flux de travail enfants pour détecter les erreurs dans le flux de travail parent. Vous pouvez également choisir d'écouter les `TIMED_OUT` événements des flux de travail standard à l'aide d'un EventBridge bus et d'invoquer une action pour gérer l'échec de l'exécution. **Exemples pratiques de gestion des erreurs** Pour déployer un exemple de flux de travail incluant la gestion des erreurs, consultez le [Gestion des conditions d'erreur dans une machine à états Step Functions](tutorial-handling-error-conditions.md) didacticiel de ce guide et la [gestion des erreurs](https://catalog.workshops.aws/stepfunctions/handling-errors) dans *The AWS Step Functions Workshop*. ## Noms des erreurs Step Functions identifie les erreurs à l'aide de chaînes distinguant majuscules et minuscules, appelées *noms d'erreur*. L'Amazon States Language définit un ensemble de chaînes intégrées qui nomment les erreurs connues, en commençant toutes par le `States.` préfixe. Les états peuvent signaler les erreurs avec d'autres noms. Toutefois, le nom des erreurs ne peut pas commencer par le `States.` préfixe. Assurez-vous que votre code de production peut gérer les exceptions de AWS Lambda service (`Lambda.ServiceException`et`Lambda.SdkClientException`). Pour plus d'informations, consultez la section *Bonnes pratiques pour [Gérer les exceptions transitoires du service Lambda](sfn-best-practices.md#bp-lambda-serviceexception) savoir comment procéder*. ** `States.ALL` ** Un caractère générique qui correspond à n'importe quel nom d'erreur connu. Le type `States.ALL` d'erreur doit apparaître seul dans un `Catcher` et ne peut pas détecter l'erreur du `States.DataLimitExceeded` terminal ou les types `Runtime` d'erreur. Pour plus d’informations, consultez [`States.DataLimitExceeded`](#error-data-limit-exceed) et [`States.Runtime`](#states-runtime-error). ** `States.DataLimitExceeded` ** Une erreur de terminal qui ne peut pas être détectée par le type `States.ALL` d'erreur. Signalé en raison des conditions suivantes : + La sortie d'un connecteur est supérieure au quota de taille de charge utile. + La sortie d'un état est supérieure au quota de taille de charge utile. + Après le `Parameters` traitement, l'entrée d'un état est supérieure au quota de taille de charge utile. Pour plus d'informations sur les quotas, voir[Quotas de service Step Functions](service-quotas.md). **`States.ExceedToleratedFailureThreshold`** Un `Map` état a échoué car le nombre d'éléments défaillants a dépassé le seuil spécifié dans la définition de la machine à états. Pour de plus amples informations, veuillez consulter [Définition de seuils de défaillance pour les états des cartes distribuées dans Step Functions](state-map-distributed.md#maprun-fail-threshold). ** `States.HeartbeatTimeout` ** Un `Task` état n'a pas réussi à envoyer un battement de cœur pendant une période supérieure à la `HeartbeatSeconds` valeur. `HeartbeatTimeout`est disponible dans les `Retry` champs `Catch` et. ** `States.Http.Socket` ** Se produit lorsqu'une tâche HTTP expire au bout de 60 secondes. Consultez [Quotas liés à la tâche HTTP](service-quotas.md#service-limits-http-task). **`States.ItemReaderFailed`** Un `Map` état a échoué car il n'a pas pu lire à partir de la source de l'élément spécifiée dans le `ItemReader` champ. Pour de plus amples informations, veuillez consulter `ItemReader (Carte)`. ** `States.Permissions` ** Un `Task` état a échoué car il ne disposait pas de privilèges suffisants pour exécuter le code spécifié. **`States.ResultWriterFailed`** Un `Map` état a échoué car il n'a pas pu écrire les résultats vers la destination spécifiée dans le `ResultWriter` champ. Pour de plus amples informations, veuillez consulter `ResultWriter (Carte)`. **`States.Runtime`** Une exécution a échoué en raison d'une exception qu'elle n'a pas pu traiter. Souvent, ces erreurs sont causées par des erreurs lors de l'exécution, telles que la tentative d'application `InputPath` ou `OutputPath` sur une charge utile JSON nulle. Une `States.Runtime` erreur n'est pas récupérable et entraîne toujours l'échec de l'exécution. Une nouvelle tentative ou un catch on `States.ALL` ne détectera pas `States.Runtime` les erreurs. ** `States.TaskFailed` ** L'état `Task` a échoué au cours de l'exécution. Lorsqu'il est utilisé dans un retry ou un catch, `States.TaskFailed` agit comme un caractère générique qui correspond à n'importe quel nom d'erreur connu, à l'exception de. `States.Timeout` ** `States.Timeout` ** Signalé lorsqu'un `Task` état est supérieur à la `TimeoutSeconds` valeur ou qu'il n'a pas réussi à envoyer de battement de cœur pendant une période supérieure à la `HeartbeatSeconds` valeur. Si une *machine à états imbriqués* lance un`States.Timeout`, le parent recevra une `States.TaskedFailed` erreur. Une `States.Timeout` erreur est également signalée lorsque l'exécution complète d'une machine à états dure plus longtemps que la `TimeoutSeconds` valeur spécifiée. **Note** Les erreurs non gérées dans les environnements d'exécution Lambda étaient historiquement signalées uniquement sous la forme. `Lambda.Unknown` Dans les nouveaux environnements d'exécution, les délais d'expiration sont signalés comme `Sandbox.Timedout` dans le résultat d'erreur. Lorsque Lambda dépasse le nombre maximum d'appels, l'erreur signalée sera. `Lambda.TooManyRequestsException` Faites correspondre `Lambda.Unknown``Sandbox.Timedout`, et `States.TaskFailed` pour gérer les erreurs éventuelles. Vous pouvez également l'utiliser`States.ALL`, mais il doit être seul et en fin de liste. Pour plus d'informations sur Lambda `Handled` et `Unhandled` les erreurs, consultez le `FunctionError` manuel du [AWS Lambda développeur](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseSyntax). ## Nouvelle tentative après une erreur `Task``Parallel`, et `Map` les états peuvent avoir un champ nommé`Retry`, dont la valeur doit être un tableau d'objets appelés *retriers.* Un réessayeur représente un certain nombre de nouvelles tentatives, généralement à intervalles de temps croissants. Lorsque l'un de ces états signale une erreur et qu'un `Retry` champ apparaît, Step Functions parcourt les récupérateurs dans l'ordre indiqué dans le tableau. Lorsque le nom de l'erreur apparaît dans la valeur du `ErrorEquals` champ d'un récupérateur, la machine à états effectue de nouvelles tentatives comme indiqué dans le `Retry` champ. Si votre redriven exécution réexécute un [état [État du flux de travail des tâches](state-task.md)[État du flux de travail parallèle](state-parallel.md), ou Inline Map](state-map-inline.md), pour lequel vous avez défini de nouvelles [tentatives](#error-handling-retrying-after-an-error), le nombre de tentatives pour ces états est remis à 0 pour tenir compte du nombre maximum de tentatives. redrive Pour une redriven exécution, vous pouvez suivre les tentatives de tentative individuelles de ces états à l'aide de la console. Pour plus d’informations, consultez [Réessayer le comportement des exécutions redriven](redrive-executions.md#redrive-retry-behavior) dans [Redémarrer les exécutions de State Machine avec redrive in Step Functions](redrive-executions.md). Un réessayeur contient les champs suivants : ** `ErrorEquals` (Obligatoire)** Tableau non vide de chaînes qui correspondent aux noms d'erreur. Lorsqu'un état signale une erreur, Step Functions analyse les récupérateurs. Lorsque le nom de l'erreur apparaît dans ce tableau, il met en œuvre la stratégie de nouvelle tentative décrite dans ce réessayeur. ** `IntervalSeconds` (facultatif)** Un entier positif qui représente le nombre de secondes avant la première tentative (`1`par défaut). `IntervalSeconds`a une valeur maximale de 99999999. ** `MaxAttempts` (facultatif)** Nombre entier positif qui représente le nombre maximum de nouvelles tentatives (`3` par défaut). Si l'erreur se produit un nombre de fois supérieur à la valeur spécifiée, les nouvelles tentatives cessent et la gestion normale des erreurs reprend. La valeur de `0` indique que l'erreur n'est jamais réessayée. `MaxAttempts`a une valeur maximale de 99999999. ** `BackoffRate` (facultatif)** Multiplicateur par lequel l'intervalle de tentatives indiqué par `IntervalSeconds` augmente après chaque nouvelle tentative. Par défaut, la valeur `BackoffRate` augmente de `2.0`. Par exemple, disons `IntervalSeconds` que vous êtes `MaxAttempts` 3, 3 et `BackoffRate` 2. La première tentative a lieu trois secondes après l'apparition de l'erreur. La deuxième tentative a lieu six secondes après la première tentative. Alors que la troisième tentative a lieu 12 secondes après la deuxième tentative. ** `MaxDelaySeconds` (facultatif) ** Nombre entier positif qui définit la valeur maximale, en secondes, jusqu'à laquelle un intervalle de tentatives peut être augmenté. Ce champ est utile à utiliser avec le `BackoffRate` champ. La valeur que vous spécifiez dans ce champ limite les temps d'attente exponentiels résultant du multiplicateur du taux de ralentissement appliqué à chaque nouvelle tentative consécutive. Vous devez spécifier une valeur supérieure à 0 et inférieure à 31622401 pour. `MaxDelaySeconds` Si vous ne spécifiez pas cette valeur, Step Functions ne limite pas les temps d'attente entre les nouvelles tentatives. ** `JitterStrategy` (facultatif) ** Chaîne qui détermine s'il faut ou non inclure la gigue dans les temps d'attente entre deux tentatives consécutives. Jitter réduit le nombre de tentatives simultanées en les répartissant sur un intervalle de temporisation aléatoire. Cette chaîne accepte `FULL` ou `NONE` comme valeurs. La valeur par défaut est `NONE`. Supposons, par exemple, que vous ayez défini `MaxAttempts` `IntervalSeconds` comme 3, comme 2 et `BackoffRate` comme 2. La première nouvelle tentative a lieu deux secondes après la survenue de l’erreur. La deuxième nouvelle tentative a lieu quatre secondes après la première nouvelle tentative et la troisième nouvelle tentative a lieu huit secondes après la deuxième nouvelle tentative. Si vous définissez `JitterStrategy` comme`FULL`, le premier intervalle de tentatives est randomisé entre 0 et 2 secondes, le deuxième intervalle entre 0 et 4 secondes, et le troisième intervalle entre 0 et 8 secondes. **Note** Les nouvelles tentatives sont traitées comme des transitions d'état. Pour plus d'informations sur l'impact des transitions entre États sur la facturation, consultez [Step Functions Pricing](https://aws.amazon.com/step-functions/pricing/). ### Exemples de champs à réessayer Cette section inclut les exemples de `Retry` champs suivants. + [Retry with BackoffRate](#retrybackoffrate) + [Retry with MaxDelaySeconds](#retrymaxdelayseconds) + [Retry all errors except States.Timeout](#retrytimeout) + [Complex retry scenario](#complexretryeg) **Exemple 1 — Réessayez avec BackoffRate** L'exemple suivant montre `Retry` deux tentatives de tentative, la première ayant lieu après trois secondes d'attente. En fonction de ce `BackoffRate` que vous spécifiez, Step Functions augmente l'intervalle entre chaque nouvelle tentative jusqu'à ce que le nombre maximum de tentatives soit atteint. Dans l'exemple suivant, la deuxième tentative commence après une attente de trois secondes après la première tentative. ``` "Retry": [ { "ErrorEquals": [ "States.Timeout" ], "IntervalSeconds": 3, "MaxAttempts": 2, "BackoffRate": 1 } ] ``` **Exemple 2 — Réessayez avec MaxDelaySeconds** L'exemple suivant effectue trois tentatives de nouvelle tentative et limite le temps d'attente `BackoffRate` à 5 secondes. La première nouvelle tentative a lieu après trois secondes d’attente. Les deuxième et troisième nouvelles tentatives ont lieu après une attente de cinq secondes après la nouvelle tentative précédente en raison de la limite de temps d’attente maximale fixée par `MaxDelaySeconds`. ``` "Retry": [ { "ErrorEquals": [ "States.Timeout" ], "IntervalSeconds": 3, "MaxAttempts": 3, "BackoffRate":2, "MaxDelaySeconds": 5, "JitterStrategy": "FULL" } ] ``` Sans `MaxDelaySeconds`, la deuxième nouvelle tentative aurait lieu six secondes après la première nouvelle tentative, et la troisième nouvelle tentative aurait lieu 12 secondes après la deuxième. **Exemple 3 — Réessayez toutes les erreurs sauf States.Timeout** Le nom réservé `States.ALL` qui apparaît dans le champ `ErrorEquals` du Réessayeur est une valeur générique correspondant à n'importe quel nom d'erreur. Il doit apparaître seul dans le tableau `ErrorEquals` et doit figurer dans le dernier réessayeur du tableau `Retry`. Le nom agit `States.TaskFailed` également comme un caractère générique et correspond à toutes les erreurs, à l'exception de`States.Timeout`. Dans l'exemple de `Retry` champ suivant, une nouvelle tentative d'erreur est effectuée, sauf`States.Timeout`. ``` "Retry": [ { "ErrorEquals": [ "States.Timeout" ], "MaxAttempts": 0 }, { "ErrorEquals": [ "States.ALL" ] } ] ``` **Exemple 4 — Scénario de nouvelle tentative complexe** Les paramètres d'un réessayeur s'appliquent à toutes les visites de ce réessayeur dans le cadre d'une seule exécution d'état. Prenons l'exemple de l'état `Task` suivant : ``` "X": { "Type": "Task", "Resource": "arn:aws:states:region:123456789012:task:X", "Next": "Y", "Retry": [ { "ErrorEquals": [ "ErrorA", "ErrorB" ], "IntervalSeconds": 1, "BackoffRate": 2.0, "MaxAttempts": 2 }, { "ErrorEquals": [ "ErrorC" ], "IntervalSeconds": 5 } ], "Catch": [ { "ErrorEquals": [ "States.ALL" ], "Next": "Z" } ] } ``` Cette tâche échoue quatre fois de suite et affiche les noms d'erreur suivants :`ErrorA`, `ErrorB``ErrorC`, et`ErrorB`. Voici ce qui se produit ensuite : + Les deux premières erreurs correspondent au premier retrier et entraînent des temps d'attente d'une ou deux secondes. + La troisième erreur correspond au deuxième retrier et entraîne une attente de cinq secondes. + La quatrième erreur correspond également au premier retrier. Cependant, il a déjà atteint son maximum de deux tentatives (`MaxAttempts`) pour cette erreur particulière. Par conséquent, ce récupérateur échoue et l'exécution redirige le flux de travail vers l'`Z`état via le `Catch` champ. ## États de secours `Task`, `Map` et `Parallel` les états peuvent chacun avoir un champ nommé`Catch`. La valeur de ce champ doit être un tableau d'objets, nommés *receveurs*. Un receveur contient les champs suivants. ** `ErrorEquals` (Obligatoire)** Un tableau non vide de chaînes qui correspondent à des noms d'erreur, spécifiées exactement comme dans le champ de réessayeur du même nom. ** `Next` (Obligatoire)** Une chaîne qui doit correspondre exactement à l'un des noms d'état de la machine d'état. ** `ResultPath`(JSONPath, Facultatif)** Un [chemin](concepts-input-output-filtering.md) qui détermine l'entrée que le receveur envoie à l'état spécifié dans le `Next` champ. Lorsqu'un État signale une erreur et qu'il n'y a aucun `Retry` champ, ou si les tentatives échouent à résoudre l'erreur, Step Functions analyse les capteurs dans l'ordre indiqué dans le tableau. Lorsque le nom de l'erreur apparaît dans la valeur du champ `ErrorEquals` d'un receveur, la machine d'état passe à l'état nommé dans le champ `Next`. Le nom réservé `States.ALL` qui apparaît dans le champ `ErrorEquals` du receveur est une valeur générique correspondant à n'importe quel nom d'erreur. Il doit apparaître seul dans le tableau `ErrorEquals` et doit figurer dans le dernier receveur du tableau `Catch`. Le nom agit `States.TaskFailed` également comme un caractère générique et correspond à toutes les erreurs, à l'exception de`States.Timeout`. L’exemple suivant d’un champ `Catch` passe à l’état nommé `RecoveryState` lorsqu’une fonction Lambda génère une exception Java non gérée. Sinon, le champ passe à l’état `EndState`. ``` "Catch": [ { "ErrorEquals": [ "java.lang.Exception" ], "ResultPath": "$.error-info", "Next": "RecoveryState" }, { "ErrorEquals": [ "States.ALL" ], "Next": "EndState" } ] ``` **Combien d'erreurs un catcher peut-il détecter ?** Chaque receveur peut spécifier **plusieurs erreurs** à traiter. ### Sortie d'erreur Lorsque Step Functions passe à l'état spécifié dans un catch name, l'objet contient généralement le champ`Cause`. La valeur de ce champ est une description lisible de l'erreur. Cet objet est connu sous le nom de *sortie de l'erreur*. Dans l' JSONPath exemple précédent, le premier capteur contient un `ResultPath` champ. Cela fonctionne de la même manière qu'un champ `ResultPath` au niveau supérieur d'un état, ce qui se traduit par deux possibilités : + Prenez les résultats de l'exécution de cet état et remplacez la totalité ou une partie de l'entrée de l'état. + Prenez les résultats et ajoutez-les à l'entrée. Dans le cas d'une erreur gérée par un catcher, le résultat de l'exécution de l'état est la sortie d'erreur. Ainsi, pour le premier capteur de l'exemple, le capteur ajoute la sortie d'erreur à l'entrée sous forme de champ nommé `error-info` s'il n'existe pas déjà de champ portant ce nom dans l'entrée. Ensuite, le receveur envoie l'intégralité de l'entrée à`RecoveryState`. Pour le second capteur, la sortie d'erreur remplace l'entrée et le capteur envoie uniquement la sortie d'erreur à. `EndState` Pour les JSONPath flux de travail, si vous ne spécifiez pas le `ResultPath` champ, la valeur par défaut est`$`, qui sélectionne et remplace l'intégralité de l'entrée. Lorsqu'un état possède à la fois `Retry` des `Catch` champs et, Step Functions utilise d'abord les récupérateurs appropriés. Si la politique de nouvelles tentatives ne parvient pas à résoudre l'erreur, Step Functions applique la transition de capture correspondante. ### Provoquer des charges utiles et des intégrations de services Un catcher renvoie une charge utile sous forme de chaîne en sortie. Lorsque vous travaillez avec des intégrations de services telles qu'Amazon Athena AWS CodeBuild ou, vous souhaiterez peut-être convertir `Cause` la chaîne en JSON. L'exemple suivant d'`Pass`état avec des fonctions intrinsèques montre comment convertir une `Cause` chaîne en JSON. ``` "Handle escaped JSON with JSONtoString": { "Type": "Pass", "Parameters": { "Cause.$": "States.StringToJson($.Cause)" }, "Next": "Pass State with Pass Processing" }, ``` ## Exemples de machines à états utilisant Retry et Catch Les machines à états définies dans les exemples suivants supposent l'existence de deux fonctions Lambda : l'une qui échoue toujours et l'autre qui attend suffisamment longtemps pour qu'un délai défini dans la machine à états se produise. Il s'agit de la définition d'une fonction Lambda Node.js qui échoue toujours et renvoie le message. `error` Dans les exemples de machine à états suivants, cette fonction Lambda est nommée. `FailFunction` Pour plus d'informations sur la création d'une fonction Lambda, reportez-vous [Étape 1 : créer une fonction Lambda](tutorial-creating-lambda-state-machine.md#create-lambda-function) à la section. ``` exports.handler = (event, context, callback) => { callback("error"); }; ``` Il s'agit de la définition d'une fonction Lambda de Node.js qui est en veille pendant 10 secondes. Dans les exemples de machine à états suivants, cette fonction Lambda est nommée. `sleep10` ``` exports.handler = (event, context, callback) => { setTimeout(function(){ }, 11000); }; ``` **Réglages du délai d'expiration de la fonction** Lorsque vous créez la fonction Lambda pour les exemples, n'oubliez pas de définir la `Timeout` valeur sur 11 secondes dans les paramètres avancés. ### Gérer un échec à l'aide de Retry Cette machine d'état utilise un champ `Retry` pour réessayer une fonction qui échoue et génère le nom d'erreur `HandledError`. Il réessaie cette fonction deux fois avec un décalage exponentiel entre les tentatives. ``` { "Comment": "A Hello World example invoking Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:region:123456789012:function:FailFunction", "Retry": [ { "ErrorEquals": ["HandledError"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 } ], "End": true } } } ``` Cette variante utilise le code d'erreur prédéfini`States.TaskFailed`, qui correspond à toute erreur générée par une fonction Lambda. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:region:123456789012:function:FailFunction", "Retry": [ { "ErrorEquals": ["States.TaskFailed"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 } ], "End": true } } } ``` **Bonnes pratiques pour gérer les exceptions Lambda** Les tâches qui font référence à une fonction Lambda doivent gérer les exceptions de service Lambda. Pour plus d'informations, consultez [Gérer les exceptions transitoires du service Lambda](sfn-best-practices.md#bp-lambda-serviceexception) la section Bonnes pratiques. ### Gérer une panne à l'aide de Catch Cet exemple utilise un champ `Catch`. Lorsqu'une fonction Lambda génère une erreur, elle détecte l'erreur et la machine à états passe à l'`fallback`état. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:region:123456789012:function:FailFunction", "Catch": [ { "ErrorEquals": ["HandledError"], "Next": "fallback" } ], "End": true }, "fallback": { "Type": "Pass", "Result": "Hello, AWS Step Functions!", "End": true } } } ``` Cette variante utilise le code d'erreur prédéfini`States.TaskFailed`, qui correspond à toute erreur générée par une fonction Lambda. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:region:123456789012:function:FailFunction", "Catch": [ { "ErrorEquals": ["States.TaskFailed"], "Next": "fallback" } ], "End": true }, "fallback": { "Type": "Pass", "Result": "Hello, AWS Step Functions!", "End": true } } } ``` ### Gestion d'un délai d'attente à l'aide de Retry Cette machine à états utilise un `Retry` champ pour réessayer un `Task` état expirant, en fonction de la valeur de délai spécifiée dans. `TimeoutSeconds` Step Functions réessaie deux fois d'invoquer la fonction Lambda dans `Task` cet état, avec un décalage exponentiel entre les tentatives. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:region:123456789012:function:sleep10", "TimeoutSeconds": 2, "Retry": [ { "ErrorEquals": ["States.Timeout"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 } ], "End": true } } } ``` ### Gérer un délai d'attente à l'aide de Catch Cet exemple utilise un champ `Catch`. Lorsqu'un délai arrive à expiration, la machine d'état passe à l'état `fallback`. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:region:123456789012:function:sleep10", "TimeoutSeconds": 2, "Catch": [ { "ErrorEquals": ["States.Timeout"], "Next": "fallback" } ], "End": true }, "fallback": { "Type": "Pass", "Result": "Hello, AWS Step Functions!", "End": true } } } ``` **Préservation de la saisie d'état et des erreurs dans JSONPath** Dans JSONPath, vous pouvez conserver l'état saisi et l'erreur en utilisant`ResultPath`. Consultez [ResultPath À utiliser pour inclure à la fois une erreur et une entrée dans un `Catch`](input-output-resultpath.md#input-output-resultpath-catch).