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:

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.

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.ServiceExceptioneLambda.SdkClientException). Per ulteriori informazioni, consulta la sezione Procedure ottimali. Gestire le eccezioni transitorie del servizio Lambda

Nuovo tentativo dopo un errore

TaskParallel, e Map gli stati possono avere un campo denominatoRetry, 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 statoStato del flusso di lavoro delle attività, o Inline Map Stato del flusso di lavoro parallelo, per il quale sono stati definiti nuovi tentativi, il conteggio dei tentativi 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 in Riavvio delle esecuzioni delle macchine a stati con redrive Step Functions.

Un retrier contiene i seguenti campi:

Riprova gli esempi di campi

Questa sezione include i seguenti esempi di Retry campo.

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:

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.

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"
} ]

Output dell'errore

Quando Step Functions passa allo stato specificato in un catch name, l'oggetto di solito contiene il campoCause. 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à:

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: Creazione di una funzione Lambda 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);
};

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 predefinitoStates.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
      }
   }
}

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 predefinitoStates.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
      }
   }
}