Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Gestione degli errori nei flussi di lavoro di Step Functions Tutti gli stati, tranne `Wait` gli stati `Pass` e, possono presentare errori di runtime. Gli errori possono verificarsi per vari motivi, tra cui: + **Problemi di definizione della macchina a stati**, ad esempio uno stato di scelta senza una regola corrispondente + **Errori nelle attività**, ad esempio un'eccezione in una AWS Lambda funzione + **Problemi transitori**, ad esempio eventi di partizione di rete Quando uno stato segnala un errore, per impostazione predefinita Step Functions fallisce **l'intera** esecuzione della macchina a stati. Step Functions dispone anche di funzioni di gestione degli errori più avanzate. Puoi configurare la tua state machine per catturare errori, riprovare gli stati falliti e implementare correttamente i protocolli di gestione degli errori. Gli Step Functions catcher sono disponibili per gli stati **Task**, **Parallel** e **Map**, ma non per gli errori di esecuzione delle macchine a stati di primo livello. Per gestire le esecuzioni che si prevede possano fallire, il chiamante può gestire l'errore oppure è possibile inserire tali esecuzioni all'interno di flussi di lavoro secondari per rilevare gli errori all'interno del flusso di lavoro principale. In alternativa, puoi scegliere di ascoltare `TIMED_OUT` gli eventi dei flussi di lavoro Standard con un EventBridge bus e richiamare un'azione per gestire l'esecuzione non riuscita. **Esempi pratici per la gestione degli errori** Per implementare un esempio di flusso di lavoro che include la gestione degli errori, consultate il [Gestione delle condizioni di errore in una macchina a stati Step Functions](tutorial-handling-error-conditions.md) tutorial in questa guida e la [gestione degli errori](https://catalog.workshops.aws/stepfunctions/handling-errors) in *The AWS Step Functions Workshop*. ## Nomi degli errori *Step Functions identifica gli errori utilizzando stringhe con distinzione tra maiuscole e minuscole, note come nomi di errore.* Amazon States Language definisce un set di stringhe integrate che denominano errori noti, tutti a partire dal `States.` prefisso. Gli stati possono riportare errori con altri nomi. Tuttavia, i nomi degli errori non possono iniziare con il `States.` prefisso. Assicurati che il codice di produzione sia in grado di gestire le eccezioni di AWS Lambda servizio (`Lambda.ServiceException`e`Lambda.SdkClientException`). Per ulteriori informazioni, consulta la sezione *Procedure ottimali*. [Gestire le eccezioni transitorie del servizio Lambda](sfn-best-practices.md#bp-lambda-serviceexception) ** `States.ALL` ** Un carattere jolly che corrisponde a qualsiasi nome di errore noto. Il tipo di `States.ALL` errore deve apparire da solo in a `Catcher` e non può catturare l'errore o i tipi di `Runtime` errore del `States.DataLimitExceeded` terminale. Per ulteriori informazioni, consultare [`States.DataLimitExceeded`](#error-data-limit-exceed) e [`States.Runtime`](#states-runtime-error). ** `States.DataLimitExceeded` ** Un errore terminale che non può essere rilevato dal tipo di `States.ALL` errore. Segnalato a causa delle seguenti condizioni: + L'uscita di un connettore è superiore alla quota di dimensione del payload. + L'output di uno stato è maggiore della quota di dimensione del payload. + Dopo l'`Parameters`elaborazione, l'input di uno stato è maggiore della quota di dimensione del payload. Per ulteriori informazioni sulle quote, vedere. [Quote di servizio Step Functions](service-quotas.md) **`States.ExceedToleratedFailureThreshold`** Uno `Map` stato non è riuscito perché il numero di elementi non riusciti ha superato la soglia specificata nella definizione della macchina a stati. Per ulteriori informazioni, consulta [Impostazione delle soglie di errore per gli stati della mappa distribuita in Step Functions](state-map-distributed.md#maprun-fail-threshold). ** `States.HeartbeatTimeout` ** Uno `Task` stato non è riuscito a inviare un battito cardiaco per un periodo più lungo del `HeartbeatSeconds` valore. `HeartbeatTimeout`è disponibile all'interno dei `Retry` campi `Catch` and. ** `States.Http.Socket` ** Si verifica quando un'attività HTTP scade dopo 60 secondi. Per informazioni, consulta [Quote relative a HTTP Task](service-quotas.md#service-limits-http-task). **`States.ItemReaderFailed`** Uno `Map` stato non è riuscito perché non è in grado di leggere la fonte dell'elemento specificata nel `ItemReader` campo. Per ulteriori informazioni, consulta `ItemReader (Mappa)`. ** `States.Permissions` ** Uno `Task` stato non è riuscito perché non disponeva di privilegi sufficienti per eseguire il codice specificato. **`States.ResultWriterFailed`** Uno `Map` stato non è riuscito perché non è stato in grado di scrivere risultati nella destinazione specificata nel `ResultWriter` campo. Per ulteriori informazioni, consulta `ResultWriter (Mappa)`. **`States.Runtime`** Un'esecuzione non è riuscita a causa di un'eccezione che non è stata in grado di elaborare. Spesso questo è causato da errori in fase di esecuzione, come il tentativo di applicare `InputPath` o `OutputPath` su un payload JSON null. Un `States.Runtime` errore non è recuperabile e causerà sempre il fallimento dell'esecuzione. Un nuovo tentativo o un catch on `States.ALL` non rileveranno `States.Runtime` errori. ** `States.TaskFailed` ** Uno stato `Task` ha avuto esito negativo durante l'esecuzione. Quando viene utilizzato in un retry o catch, `States.TaskFailed` funge da jolly che corrisponde a qualsiasi nome di errore noto ad eccezione di. `States.Timeout` ** `States.Timeout` ** Segnalato quando uno `Task` stato dura più a lungo del `TimeoutSeconds` valore o non è riuscito a inviare un heartbeat per un periodo più lungo del valore. `HeartbeatSeconds` Se una *macchina a stati annidata* genera un`States.Timeout`, il genitore riceverà un errore. `States.TaskedFailed` Viene inoltre segnalato un `States.Timeout` errore quando l'esecuzione di un'intera macchina a stati dura più a lungo del valore specificato`TimeoutSeconds`. **Nota** Gli errori non gestiti nei runtime Lambda venivano storicamente riportati solo come. `Lambda.Unknown` Nei runtime più recenti, i timeout vengono segnalati come nell'output degli errori. `Sandbox.Timedout` Quando Lambda supera il numero massimo di chiamate, verrà segnalato l'errore. `Lambda.TooManyRequestsException` Match on `Lambda.Unknown``Sandbox.Timedout`, e `States.TaskFailed` per gestire possibili errori. Puoi anche usarlo`States.ALL`, ma deve essere da solo e alla fine dell'elenco. Per ulteriori informazioni su Lambda `Handled` e sugli `Unhandled` errori, consulta `FunctionError` la [AWS Lambda Developer](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseSyntax) Guide. ## Nuovo tentativo dopo un errore `Task``Parallel`, e `Map` gli stati possono avere un campo denominato`Retry`, il cui valore deve essere una matrice di oggetti noti come *retrier*. Un singolo retrier rappresenta un determinato numero di tentativi, di solito a intervalli di tempo crescenti. Quando uno di questi stati segnala un errore ed è presente un `Retry` campo, Step Functions analizza i retrier nell'ordine elencato nell'array. Quando il nome dell'errore compare nel valore del `ErrorEquals` campo di un retrier, la macchina a stati esegue nuovi tentativi come definito nel campo. `Retry` Se redriven l'esecuzione esegue [nuovamente [uno stato[Stato del flusso di lavoro delle attività](state-task.md), o Inline Map [Stato del flusso di lavoro parallelo](state-parallel.md)](state-map-inline.md), per il quale sono stati definiti nuovi tentativi, il conteggio dei tentativi](#error-handling-retrying-after-an-error) per questi stati viene ripristinato a 0 per consentire il numero massimo di tentativi. redrive Per un'redrivenesecuzione, è possibile tenere traccia dei singoli tentativi di nuovi tentativi di questi stati utilizzando la console. Per ulteriori informazioni, consulta [Riprova il comportamento delle esecuzioni redriven](redrive-executions.md#redrive-retry-behavior) in [Riavvio delle esecuzioni delle macchine a stati con redrive Step Functions](redrive-executions.md). Un retrier contiene i seguenti campi: ** `ErrorEquals` (Obbligatorio)** Un array non vuoto di stringhe che corrispondono a nomi di errore. Quando uno stato segnala un errore, Step Functions analizza i retrier. Quando nell'array compare il nome dell'errore, implementa la policy per i nuovi tentativi descritta nel retrier. ** `IntervalSeconds` (facoltativo).** Un numero intero positivo che rappresenta il numero di secondi prima del primo tentativo (`1`per impostazione predefinita). `IntervalSeconds`ha un valore massimo di 99999999. ** `MaxAttempts` (facoltativo).** Un numero intero positivo che rappresenta il numero massimo di tentativi (`3` per impostazione predefinita). Se l'errore si ripete più volte di quanto specificato, i tentativi cessano e viene ripristinata la gestione normale degli errori. Il valore di `0` specifica che l'errore non viene mai ritentato. `MaxAttempts`ha un valore massimo di 99999999. ** `BackoffRate` (facoltativo).** Il moltiplicatore con il quale l'intervallo di tentativi indicato da `IntervalSeconds` aumenta dopo ogni nuovo tentativo. Per impostazione predefinita, il valore `BackoffRate` aumenta di `2.0`. Ad esempio, supponiamo che il tuo `IntervalSeconds` sia 3, sia 3 e `MaxAttempts` sia 2. `BackoffRate` Il primo tentativo viene eseguito tre secondi dopo il verificarsi dell'errore. Il secondo tentativo ha luogo sei secondi dopo il primo tentativo. Mentre il terzo tentativo ha luogo 12 secondi dopo il secondo tentativo. ** `MaxDelaySeconds` (facoltativo). ** Un numero intero positivo che imposta il valore massimo, in secondi, fino al quale un intervallo di tentativi può aumentare. Questo campo è utile da usare con il campo. `BackoffRate` Il valore specificato in questo campo limita i tempi di attesa esponenziali risultanti dal moltiplicatore della frequenza di backoff applicato a ogni tentativo consecutivo. È necessario specificare un valore maggiore di 0 e minore di 31622401 per. `MaxDelaySeconds` Se non si specifica questo valore, Step Functions non limita i tempi di attesa tra un tentativo e l'altro. ** `JitterStrategy` (facoltativo). ** Una stringa che determina se includere o meno il jitter nei tempi di attesa tra tentativi consecutivi. Il jitter riduce i tentativi simultanei di nuovi tentativi distribuendoli su un intervallo di ritardo randomizzato. Questa stringa accetta or come valori. `FULL` `NONE` Il valore predefinito è `NONE`. Ad esempio, supponiamo di aver impostato `MaxAttempts` come 3, `IntervalSeconds` come 2 e `BackoffRate` come 2. Il primo nuovo tentativo viene eseguito due secondi dopo il verificarsi dell'errore. Il secondo tentativo viene eseguito quattro secondi dopo il primo tentativo e il terzo tentativo otto secondi dopo il secondo tentativo. Se si imposta `JitterStrategy` come`FULL`, il primo intervallo di tentativi viene randomizzato tra 0 e 2 secondi, il secondo intervallo tra 0 e 4 secondi e il terzo intervallo tra 0 e 8 secondi. **Nota** I nuovi tentativi vengono trattati come transizioni di stato. Per informazioni su come le transizioni di stato influiscono sulla fatturazione, consulta [Step Functions](https://aws.amazon.com/step-functions/pricing/) Pricing. ### Riprova gli esempi di campi Questa sezione include i seguenti esempi di `Retry` campo. + [Retry with BackoffRate](#retrybackoffrate) + [Retry with MaxDelaySeconds](#retrymaxdelayseconds) + [Retry all errors except States.Timeout](#retrytimeout) + [Complex retry scenario](#complexretryeg) **Esempio 1 — Riprova con BackoffRate** L'esempio seguente di a `Retry` effettua due tentativi di nuovo tentativo, il primo dopo aver atteso tre secondi. In base a `BackoffRate` quanto specificato, Step Functions aumenta l'intervallo tra ogni tentativo fino al raggiungimento del numero massimo di tentativi. Nell'esempio seguente, il secondo tentativo inizia dopo aver atteso tre secondi dopo il primo tentativo. ``` "Retry": [ { "ErrorEquals": [ "States.Timeout" ], "IntervalSeconds": 3, "MaxAttempts": 2, "BackoffRate": 1 } ] ``` **Esempio 2 — Riprova con MaxDelaySeconds** L'esempio seguente esegue tre tentativi e limita il tempo di attesa risultante `BackoffRate` a 5 secondi. Il primo tentativo viene eseguito dopo tre secondi di attesa. Il secondo e il terzo nuovo tentativo vengono eseguiti dopo aver atteso cinque secondi dopo il nuovo tentativo precedente a causa del limite di tempo massimo di attesa fissato da `MaxDelaySeconds`. ``` "Retry": [ { "ErrorEquals": [ "States.Timeout" ], "IntervalSeconds": 3, "MaxAttempts": 3, "BackoffRate":2, "MaxDelaySeconds": 5, "JitterStrategy": "FULL" } ] ``` Senza `MaxDelaySeconds`, il secondo tentativo avrebbe luogo sei secondi dopo il primo tentativo e il terzo tentativo avrebbe luogo 12 secondi dopo il secondo tentativo. **Esempio 3: riprova tutti gli errori tranne States.Timeout** Il nome riservato `States.ALL` che compare nel campo `ErrorEquals` di un retrier è un carattere jolly che corrisponde a qualsiasi nome di errore. Deve apparire da solo nell'array `ErrorEquals` e deve figurare nell'ultimo retrier dell'array `Retry`. Il nome funge `States.TaskFailed` anche da jolly e corrisponde a qualsiasi errore tranne. `States.Timeout` Il seguente esempio di `Retry` campo riprova qualsiasi errore tranne. `States.Timeout` ``` "Retry": [ { "ErrorEquals": [ "States.Timeout" ], "MaxAttempts": 0 }, { "ErrorEquals": [ "States.ALL" ] } ] ``` **Esempio 4 — Scenario di tentativi complessi** I parametri di un retrier si applicano a tutte le visite al retrier nel contesto di un'esecuzione a stato singolo. Considera lo stato `Task` seguente. ``` "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" } ] } ``` Questa attività ha esito negativo quattro volte di seguito, e vengono restituiti i seguenti nomi di errore:`ErrorA`,`ErrorB`, `ErrorC` e. `ErrorB` Il risultato è il seguente: + I primi due errori corrispondono al primo retrier e causano attese di uno e due secondi. + Il terzo errore corrisponde al secondo retrier e causa un'attesa di cinque secondi. + Il quarto errore corrisponde anche al primo retrier. Tuttavia, ha già raggiunto il numero massimo di due tentativi (`MaxAttempts`) per quel particolare errore. Pertanto, quel retrier ha esito negativo e l'esecuzione reindirizza il flusso di lavoro `Z` allo stato tramite il campo. `Catch` ## Stati di fallback `Task`, `Map` e `Parallel` gli stati possono avere ciascuno un campo denominato. `Catch` Il valore di questo campo deve essere un array di oggetti conosciuti come *catchers*. Un catcher contiene i seguenti campi. ** `ErrorEquals` (Obbligatorio)** Un array non vuoto di stringhe che corrispondono a nomi di errore, specificati in modo identico al campo del retrier con il medesimo nome. ** `Next` (Obbligatorio)** Una stringa che deve corrispondere esattamente a uno dei nomi di stato della macchina a stati. ** `ResultPath`(JSONPath, Facoltativo)** Un [percorso](concepts-input-output-filtering.md) che determina l'input che il catcher invia allo stato specificato nel `Next` campo. Quando uno stato segnala un errore e non è presente alcun `Retry` campo o se i nuovi tentativi non riescono a risolvere l'errore, Step Functions analizza i catcher nell'ordine elencato nell'array. Quando il nome dell'errore compare nel valore del campo `ErrorEquals` di un catcher, la macchina a stati passa allo stato denominato nel campo `Next`. Il nome riservato `States.ALL` che compare nel campo `ErrorEquals` di un catcher è un carattere jolly che corrisponde a qualsiasi nome di errore. Deve apparire da solo nell'array `ErrorEquals` e deve figurare nell'ultimo catcher dell'array `Catch`. Il nome funge `States.TaskFailed` anche da jolly e corrisponde a qualsiasi errore tranne. `States.Timeout` L'esempio seguente di un campo `Catch` passa allo stato denominato `RecoveryState` quando una funzione Lambda genera un'eccezione Java non gestita. In caso contrario, il campo passa allo stato `EndState`. ``` "Catch": [ { "ErrorEquals": [ "java.lang.Exception" ], "ResultPath": "$.error-info", "Next": "RecoveryState" }, { "ErrorEquals": [ "States.ALL" ], "Next": "EndState" } ] ``` **Quanti errori può catturare un catcher?** Ogni catcher può specificare **più errori** da gestire. ### Output dell'errore Quando Step Functions passa allo stato specificato in un catch name, l'oggetto di solito contiene il campo`Cause`. Il valore di questo campo è una descrizione leggibile dell'errore. L'oggetto è noto come *output dell'errore*. Nell' JSONPath esempio precedente, il primo catcher contiene un `ResultPath` campo. Questo funziona in modo analogo a un campo `ResultPath` nel livello superiore di uno stato e genera due possibilità: + Prendi i risultati dell'esecuzione di quello stato e sovrascrivi tutto o parte dell'input dello stato. + Prendi i risultati e li aggiunge all'input. Nel caso di un errore gestito da un catcher, il risultato dell'esecuzione dello stato è l'output dell'errore. Pertanto, per il primo catcher dell'esempio, il catcher aggiunge l'output di errore all'input come campo denominato `error-info` se nell'input non è già presente un campo con questo nome. Quindi, il catcher invia l'intero input a. `RecoveryState` Per il secondo ricevitore, l'output di errore sovrascrive l'input e il catcher invia solo l'output di errore a. `EndState` Per i JSONPath flussi di lavoro, se non si specifica il `ResultPath` campo, il valore predefinito è`$`, che seleziona e sovrascrive l'intero input. Quando uno stato ha entrambi `Catch` i campi `Retry` e, Step Functions utilizza prima tutti i retrier appropriati. Se la politica di riprova non riesce a risolvere l'errore, Step Functions applica la transizione matching catcher. ### Causa payload e integrazioni di servizi Un catcher restituisce un payload di stringa come output. Quando lavori con integrazioni di servizi come Amazon Athena AWS CodeBuild o, potresti voler convertire `Cause` la stringa in JSON. Il seguente esempio di `Pass` stato con funzioni intrinseche mostra come convertire una stringa in JSON. `Cause` ``` "Handle escaped JSON with JSONtoString": { "Type": "Pass", "Parameters": { "Cause.$": "States.StringToJson($.Cause)" }, "Next": "Pass State with Pass Processing" }, ``` ## Esempi di macchine a stati che utilizzano Retry e Catch Le macchine a stati definite negli esempi seguenti presuppongono l'esistenza di due funzioni Lambda: una che fallisce sempre e una che attende abbastanza a lungo da consentire il verificarsi di un timeout definito nella macchina a stati. Questa è una definizione di una funzione Lambda di Node.js che fallisce sempre e restituisce il messaggio. `error` Negli esempi di macchine a stati che seguono, questa funzione Lambda è denominata. `FailFunction` Per informazioni sulla creazione di una funzione Lambda, vedere [Fase 1: creare una funzione Lambda](tutorial-creating-lambda-state-machine.md#create-lambda-function) la sezione. ``` exports.handler = (event, context, callback) => { callback("error"); }; ``` Questa è una definizione di una funzione Lambda di Node.js che rimane inattiva per 10 secondi. Negli esempi di macchine a stati che seguono, questa funzione Lambda è denominata. `sleep10` ``` exports.handler = (event, context, callback) => { setTimeout(function(){ }, 11000); }; ``` **Impostazioni di timeout per la funzione** Quando crei la funzione Lambda per gli esempi, ricordati di impostare il `Timeout` valore nelle impostazioni avanzate su 11 secondi. ### Gestione di un errore utilizzando Retry Questa macchina a stati utilizza un campo `Retry` per ritentare una funzione che ha esito negativo e genera il nome di errore `HandledError`. Riprova questa funzione due volte con un backoff esponenziale tra un tentativo e l'altro. ``` { "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 } } } ``` Questa variante utilizza il codice di errore predefinito`States.TaskFailed`, che corrisponde a qualsiasi errore generato da una funzione 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 } } } ``` **Le migliori pratiche per la gestione delle eccezioni Lambda** Le attività che fanno riferimento a una funzione Lambda devono gestire le eccezioni del servizio Lambda. Per ulteriori informazioni, consulta la sezione Best [Gestire le eccezioni transitorie del servizio Lambda](sfn-best-practices.md#bp-lambda-serviceexception) Practices. ### Gestione di un errore utilizzando Catch In questo esempio viene utilizzato un campo `Catch`. Quando una funzione Lambda emette un errore, rileva l'errore e la macchina a stati passa allo stato. `fallback` ``` { "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 } } } ``` Questa variante utilizza il codice di errore predefinito`States.TaskFailed`, che corrisponde a qualsiasi errore generato da una funzione 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 } } } ``` ### Gestione di un timeout utilizzando Retry Questa macchina a stati utilizza un `Retry` campo per riprovare uno `Task` stato scaduto, in base al valore di timeout specificato in. `TimeoutSeconds` Step Functions ritenta l'invocazione della funzione Lambda in `Task` questo stato due volte, con un backoff esponenziale tra un tentativo e l'altro. ``` { "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 } } } ``` ### Gestione di un timeout utilizzando Catch In questo esempio viene utilizzato un campo `Catch`. Quando si verifica un timeout, la macchina a stati passa allo stato `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 } } } ``` **Conservazione dell'input e dell'errore dello stato in JSONPath** In JSONPath, è possibile preservare l'input dello stato e l'errore utilizzando`ResultPath`. Per informazioni, consulta [ResultPath Da utilizzare per includere sia l'errore che l'input in un `Catch`](input-output-resultpath.md#input-output-resultpath-catch).