Behandlung von Zustandsfehlern in Step Functions Functions-Workflows - AWS Step Functions
Namen der FehlerWiederholter Versuch nach einem FehlerFallback-StaatenBeispiele für Zustandsmaschinen mit Retry und Catch

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Behandlung von Zustandsfehlern in Step Functions Functions-Workflows

In allen Zuständen mit Ausnahme Pass Wait von Staaten kann es zu Laufzeitfehlern kommen. Fehler können aus verschiedenen Gründen auftreten, z. B. in den folgenden Beispielen:

  • Probleme bei der Definition des Zustandsautomaten (z. B. keine übereinstimmende Regel in einem Choice-Zustand)

  • Aufgabenfehler (z. B. eine Ausnahme in einer AWS Lambda Funktion)

  • Vorübergehende Probleme (z. B. Netzwerkpartitionsereignisse)

Wenn ein Status einen Fehler meldet, schlägt die AWS Step Functions Ausführung standardmäßig vollständig fehl.

Tipp

Ein Beispiel für einen Workflow, der eine Fehlerbehandlung beinhaltet AWS-Konto, finden Sie in Modul 8 — Fehlerbehandlung von The AWS Step Functions Workshop.

Namen der Fehler

Step Functions identifiziert Fehler in der Sprache der Amazon-Staaten mithilfe von Zeichenfolgen, bei denen Groß- und Kleinschreibung beachtet wird, die als Fehlernamen bezeichnet werden. Die Amazon States Language definiert eine Reihe von integrierten Zeichenketten, die bekannte Fehler benennen, die alle mit dem States. Präfix beginnen.

States.ALL

Ein Platzhalter, der mit jedem bekannten Fehlernamen übereinstimmt.

Anmerkung

Dieser Fehlertyp kann den States.DataLimitExceeded Terminalfehlertyp und die Laufzeitfehlertypen nicht abfangen. Weitere Hinweise zu diesen Fehlertypen finden Sie unter States.DataLimitExceededund States.Runtime.

States.DataLimitExceeded

Step Functions meldet unter den folgenden Bedingungen eine States.DataLimitExceeded Ausnahme:

  • Wenn die Ausgabe eines Connectors das Kontingent für die Payload-Größe überschreitet.

  • Wenn die Ausgabe eines Zustands größer als das Payload-Größenkontingent ist.

  • Wenn nach der Parameters Verarbeitung die Eingabe eines Zustands das Kontingent für die Nutzlastgröße überschreitet.

Weitere Informationen zu Kontingenten finden Sie unterStep Functions Servicequotas.

Anmerkung

Dies ist ein Terminalfehler, der durch den States.ALL Fehlertyp nicht abgefangen werden kann.

States.ExceedToleratedFailureThreshold

Ein Map Status ist fehlgeschlagen, weil die Anzahl der ausgefallenen Elemente den in der Zustandsmaschinen-Definition angegebenen Schwellenwert überschritten hat. Weitere Informationen finden Sie unter Festlegung von Ausfallschwellenwerten für Distributed-Map-Zustände in Step Functions.

States.HeartbeatTimeout

Ein Task Status konnte für einen Zeitraum, der länger als der HeartbeatSeconds Wert war, keinen Heartbeat senden.

Anmerkung

Dieser Fehler ist nur in den Retry Feldern Catch und verfügbar.

States.IntrinsicFailure

Ein Versuch, eine systeminterne Funktion innerhalb einer Payload-Vorlage aufzurufen, ist fehlgeschlagen.

States.ItemReaderFailed

Ein Map Status ist fehlgeschlagen, weil er nicht aus der im Feld angegebenen Elementquelle lesen konnte. ItemReader Weitere Informationen finden Sie unter ItemReader (Karte).

States.NoChoiceMatched

Ein Choice Status konnte die Eingabe nicht mit den in der Auswahlregel definierten Bedingungen abgleichen, und es wurde kein Standardübergang angegeben.

States.ParameterPathFailure

Der Versuch, ein Feld innerhalb eines Parameters Statusfeldes zu ersetzen, dessen Name mit der .$ Verwendung eines Pfads endet, schlägt fehl.

States.Permissions

Ein Task Status schlug fehl, weil er nicht über ausreichende Rechte verfügte, um den angegebenen Code auszuführen.

States.ResultPathMatchFailure

Step Functions konnte das ResultPath Feld eines Bundesstaates nicht auf die Eingabe anwenden, die der Status empfangen hat.

States.ResultWriterFailed

Ein Map Status ist fehlgeschlagen, weil er keine Ergebnisse in das im ResultWriter Feld angegebene Ziel schreiben konnte. Weitere Informationen finden Sie unter ResultWriter (Karte).

States.Runtime

Eine Ausführung ist aufgrund einer Ausnahme fehlgeschlagen, die nicht verarbeitet werden konnte. Häufig werden diese Fehler durch Fehler während der Laufzeit verursacht, z. B. durch den Versuch, eine Anwendung durchzuführen, InputPath oder OutputPath durch eine JSON Null-Payload. Ein States.Runtime Fehler kann nicht wiederhergestellt werden und führt immer dazu, dass die Ausführung fehlschlägt. Ein erneuter Versuch oder ein catch On States.ALL deckt keine States.Runtime Fehler ab.

States.TaskFailed

Ein Task-Zustand ist während der Ausführung fehlgeschlagen. Wenn es in einem Wiederholungsversuch oder catch verwendet wird, States.TaskFailed fungiert es als Platzhalter, der jedem bekannten Fehlernamen entspricht, mit Ausnahme von. States.Timeout

States.Timeout

Ein Task-Zustand dauerte entweder länger als im Wert TimeoutSeconds festgelegt oder er hat für längere Zeit kein Heartbeat gesendet als im Wert HeartbeatSeconds festgelegt.

Wenn eine Zustandsmaschine länger als der angegebene TimeoutSeconds Wert läuft, schlägt die Ausführung außerdem mit einem States.Timeout Fehler fehl.

Zustände können Fehler mit anderen Namen melden. Diese Fehlernamen dürfen jedoch nicht mit dem States. Präfix beginnen.

Als bewährte Methode sollten Sie sicherstellen, dass der Produktionscode AWS Lambda Serviceausnahmen (Lambda.ServiceExceptionundLambda.SdkClientException) verarbeiten kann. Weitere Informationen finden Sie unter Behandlung für vorübergehende Lambda-Serviceausnahmen hinzufügen.

Anmerkung

Unbehandelte Fehler in Lambda werden wie Lambda.Unknown in der Fehlerausgabe gemeldet. Dazu gehören out-of-memory Fehler und Funktions-Timeouts. Sie können nach, oder abgleichen Lambda.UnknownStates.ALL, States.TaskFailed um diese Fehler zu behandeln. Wenn Lambda die maximale Anzahl von Aufrufen erreicht, lautet der Fehler. Lambda.TooManyRequestsException Weitere Informationen zu Lambda Handled und Unhandled Fehlern finden Sie FunctionError im AWS Lambda Entwicklerhandbuch.

Wiederholter Versuch nach einem Fehler

TaskParallel, und Map Staaten können ein benanntes Feld habenRetry, dessen Wert ein Array von Objekten sein muss, die als Retrier bezeichnet werden. Eine einzelner Retrier steht für eine bestimmte Anzahl von erneuten Versuchen, in der Regel in zunehmenden Zeitintervallen.

Wenn einer dieser Zustände einen Fehler meldet und es ein Retry Feld gibt, durchsucht Step Functions die Retrier in der Reihenfolge, die im Array aufgeführt ist. Wenn der Name des Fehlers im Wert eines ErrorEquals Retrier-Felds erscheint, versucht die State Machine erneut, wie im Feld definiert. Retry

Wenn Ihre redriven Ausführung einenWorkflow-Status der Aufgabe, Status des parallelen Workflows oder Inline-Map-Status wiederholt, für den Sie Wiederholungen definiert haben, wird die Anzahl der Wiederholungsversuche für diese Zustände auf 0 zurückgesetzt, um die maximale Anzahl von Versuchen zu ermöglichen. redrive Bei einer redriven Ausführung können Sie einzelne Wiederholungsversuche in diesen Zuständen mithilfe der Konsole verfolgen. Weitere Informationen finden Sie unter Versuchen Sie, das Verhalten von Ausführungen zu wiederholen redriven in RedrivingState-Machine-Ausführungen in Step Functions.

Ein Retrier enthält die folgenden Felder:

Anmerkung

Wiederholungen werden als Zustandsübergänge behandelt. Informationen darüber, wie sich Statusübergänge auf die Abrechnung auswirken, finden Sie unter Step Functions — Preisgestaltung.

ErrorEquals (Erforderlich)

Ein nicht leeres Array von Zeichenfolgen, die mit Fehlernamen übereinstimmen. Wenn ein Bundesstaat einen Fehler meldet, durchsucht Step Functions die Retrier. Wenn der Fehlername in diesem Array erscheint, implementiert es die in diesem Retrier beschriebene Wiederholungsrichtlinie.

IntervalSeconds (Optional)

Eine positive Ganzzahl, die die Anzahl der Sekunden vor dem ersten Wiederholungsversuch darstellt (1standardmäßig). IntervalSecondshat einen Höchstwert von 99999999.

MaxAttempts (Optional)

Eine positive Ganzzahl, die die maximale Anzahl von erneuten Versuchen angibt (standardmäßig 3). Wenn der Fehler öfter als angegeben erneut auftritt, erfolgen keine erneuten Versuche und die normale Fehlerbehandlung wird fortgesetzt. Ein Wert von 0 gibt an, dass der Fehler nie erneut versucht wird. MaxAttemptshat einen Höchstwert von 99999999.

BackoffRate (Optional)

Der Multiplikator, um den sich das mit bezeichnete Wiederholungsintervall nach jedem Wiederholungsversuch erhöht. IntervalSeconds Standardmäßig erhöht sich der Wert um. BackoffRate 2.0

Nehmen wir zum Beispiel an, Ihr IntervalSeconds Wert MaxAttempts ist 3, ist 3 und BackoffRate ist 2. Der erste Wiederholungsversuch erfolgt drei Sekunden nach dem Auftreten des Fehlers. Der zweite Versuch erfolgt sechs Sekunden nach dem ersten Wiederholungsversuch. Während der dritte Wiederholungsversuch 12 Sekunden nach dem zweiten Wiederholungsversuch stattfindet.

MaxDelaySeconds (Optional)

Eine positive Ganzzahl, die den Höchstwert in Sekunden festlegt, bis zu dem ein Wiederholungsintervall verlängert werden kann. Es ist hilfreich, dieses Feld zusammen mit dem BackoffRate Feld zu verwenden. Der Wert, den Sie in diesem Feld angeben, begrenzt die exponentiellen Wartezeiten, die sich aus dem Multiplikator für die Backoff-Rate ergeben, der auf jeden aufeinanderfolgenden Wiederholungsversuch angewendet wird. Sie müssen einen Wert größer als 0 und kleiner als 31622401 für angeben. MaxDelaySeconds

Wenn Sie diesen Wert nicht angeben, begrenzt Step Functions die Wartezeiten zwischen Wiederholungsversuchen nicht.

JitterStrategy (Optional)

Eine Zeichenfolge, die bestimmt, ob Jitter in die Wartezeiten zwischen aufeinanderfolgenden Wiederholungsversuchen einbezogen werden soll oder nicht. Jitter reduziert gleichzeitige Wiederholungsversuche, indem diese über ein zufälliges Verzögerungsintervall verteilt werden. Diese Zeichenfolge akzeptiert FULL oder NONE als ihre Werte. Der Standardwert ist NONE.

Nehmen wir zum Beispiel an, Sie haben den Wert MaxAttempts als 3, IntervalSeconds als 2 und BackoffRate als 2 festgelegt. Der erste Wiederholungsversuch erfolgt zwei Sekunden nach dem Auftreten des Fehlers. Die zweite Wiederholung erfolgt vier Sekunden nach dem ersten Wiederholungsversuch und die dritte Wiederholung erfolgt acht Sekunden nach dem zweiten Wiederholungsversuch. Wenn Sie dies JitterStrategy als festlegenFULL, wird das erste Wiederholungsintervall zufällig zwischen 0 und 2 Sekunden, das zweite Wiederholungsintervall zwischen 0 und 4 Sekunden und das dritte Wiederholungsintervall zufällig zwischen 0 und 8 Sekunden.

Beispiele für Wiederholungsfelder

Dieser Abschnitt enthält die folgenden Retry Feldbeispiele.

Tipp

Ein Beispiel für einen Workflow zur Fehlerbehandlung finden Sie AWS-Konto im Modul Fehlerbehandlung von The AWS Step Functions Workshop.

Beispiel 1 — Versuchen Sie es erneut mit BackoffRate

Das folgende Beispiel für a Retry führt zwei Wiederholungsversuche durch, wobei der erste Versuch nach einer Wartezeit von drei Sekunden erfolgt. Je nachdem, was BackoffRate Sie angeben, erhöht Step Functions das Intervall zwischen den einzelnen Wiederholungsversuchen, bis die maximale Anzahl von Wiederholungsversuchen erreicht ist. Im folgenden Beispiel beginnt der zweite Wiederholungsversuch, nachdem nach dem ersten Versuch drei Sekunden gewartet wurden.

"Retry": [ {
   "ErrorEquals": [ "States.Timeout" ],
   "IntervalSeconds": 3,
   "MaxAttempts": 2,
   "BackoffRate": 1
} ]
Beispiel 2 — Versuchen Sie es erneut mit MaxDelaySeconds

Im folgenden Beispiel werden drei Wiederholungsversuche durchgeführt und die daraus resultierende Wartezeit BackoffRate auf 5 Sekunden begrenzt. Der erste Wiederholungsversuch erfolgt nach einer Wartezeit von drei Sekunden. Der zweite und dritte Wiederholungsversuch erfolgen, nachdem fünf Sekunden nach dem vorherigen Wiederholungsversuch gewartet wurden, da die maximale Wartezeit von festgelegt ist. MaxDelaySeconds

"Retry": [ {
    "ErrorEquals": [ "States.Timeout" ],
    "IntervalSeconds": 3,
    "MaxAttempts": 3,
    "BackoffRate":2,
    "MaxDelaySeconds": 5,
    "JitterStrategy": "FULL"
} ]

MaxDelaySecondsAndernfalls würde der zweite Wiederholungsversuch sechs Sekunden nach dem ersten Versuch und der dritte Wiederholungsversuch 12 Sekunden nach dem zweiten Versuch erfolgen.

Beispiel 3 — Alle Fehler außer States.Timeout wiederholen

Der reservierte Name States.ALL, der im Feld ErrorEquals eines Retriers angezeigt wird, ist ein Platzhalter, der mit jedem Fehlernamen übereinstimmt. Er muss allein im Array ErrorEquals erscheinen und er muss im letzten Retrier im Array Retry erscheinen. Der Name dient States.TaskFailed auch als Platzhalter und entspricht allen Fehlern mit Ausnahme von. States.Timeout

Das folgende Beispiel für ein Retry Feld wiederholt jeden Fehler mit Ausnahme von. States.Timeout

"Retry": [ {
   "ErrorEquals": [ "States.Timeout" ],
   "MaxAttempts": 0
}, {
   "ErrorEquals": [ "States.ALL" ]
} ]
Beispiel 4 — Komplexes Wiederholungsszenario

Die Parameter eines Retriers gelten für alle Besuche des Retriers im Kontext einer einzelnen Zustandsausführung.

Beachten Sie den folgenden Task-Zustand.

"X": {
   "Type": "Task",
   "Resource": "arn:aws:states:us-east-1: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"
   } ]
}

Diese Aufgabe schlägt viermal hintereinander fehl und gibt die folgenden Fehlernamen aus:ErrorA, ErrorBErrorC, und. ErrorB Infolgedessen geschieht Folgendes:

  • Die ersten beiden Fehler stimmen mit dem ersten Abruf überein und führen zu Wartezeiten von ein bis zwei Sekunden.

  • Der dritte Fehler entspricht dem zweiten Retrier und führt zu einer Wartezeit von fünf Sekunden.

  • Der vierte Fehler entspricht auch dem ersten Retrier. Für diesen bestimmten Fehler wurde jedoch bereits die maximale Anzahl von zwei Wiederholungen (MaxAttempts) erreicht. Daher schlägt dieser Retrier fehl und die Ausführung leitet den Workflow über das Feld in den Z Status um. Catch

Fallback-Staaten

Task, Map und für jeden Parallel Bundesstaat kann ein Feld benannt Catch werden. Der Wert dieses Felds muss eine Reihe von Objekten sein, die als Catcher bekannt sind.

Ein Catcher enthält die folgenden Felder.

ErrorEquals (Erforderlich)

Ein nicht leeres Array von Zeichenfolgen, das mit Fehlernamen übereinstimmt, genauso angegeben wie bei dem Retrier-Feld desselben Namens.

Next (Erforderlich)

Eine Zeichenfolge, die mit genau einem der Zustandsnamen des Zustandsautomaten übereinstimmen muss.

ResultPath (Optional)

Ein Pfad, der bestimmt, welche Eingabe der Catcher an den im Next Feld angegebenen Status sendet.

Wenn ein Status einen Fehler meldet und entweder kein Retry Feld vorhanden ist oder wenn der Fehler durch erneute Versuche nicht behoben werden kann, durchsucht Step Functions die Catcher in der Reihenfolge, die im Array aufgeführt ist. Wenn der Fehlername im Feld ErrorEquals eines Catchers erscheint, wechselt der Zustandsautomat in den Zustand, der im Feld Next genannt ist.

Der reservierte Name States.ALL, der im Feld ErrorEquals des Catchers erscheint, ist ein Platzhalter, der mit jedem Fehlernamen übereinstimmt. Er muss allein im Array ErrorEquals erscheinen und er muss im letzten Catcher im Array Catch erscheinen. Der Name dient States.TaskFailed auch als Platzhalter und entspricht allen Fehlern mit Ausnahme von. States.Timeout

Das folgende Beispiel zeigt, wie ein Catch Feld in den angegebenen Zustand übergeht, RecoveryState wenn eine Lambda-Funktion eine unbehandelte Java-Ausnahme ausgibt. Andernfalls wechselt das Feld in den Zustand EndState.

"Catch": [ {
   "ErrorEquals": [ "java.lang.Exception" ],
   "ResultPath": "$.error-info",
   "Next": "RecoveryState"
}, {
   "ErrorEquals": [ "States.ALL" ],
   "Next": "EndState"
} ]
Anmerkung

Jeder Catcher kann mehrere zu behandelnde Fehler angeben.

Fehlerausgabe

Wenn Step Functions in den in einem Fangnamen angegebenen Status übergeht, enthält das Objekt normalerweise das FeldCause. Der Wert dieses Felds ist eine für Menschen lesbare Beschreibung des Fehlers. Das Objekt ist als Fehlerausgabe bekannt.

In diesem Beispiel enthält der erste Catcher ein Feld ResultPath. Dies funktioniert ähnlich wie ein ResultPath-Feld im obersten Level eines Zustands, wodurch sich zwei Möglichkeiten ergeben:

  • Es verwendet die Ergebnisse der Ausführung dieses Zustands und überschreibt entweder die gesamte Eingabe des Status oder einen Teil davon.

  • Es nimmt die Ergebnisse und fügt sie der Eingabe hinzu. Im Falle eines Fehlers, der von einem Catcher behandelt wird, ist das Ergebnis der Ausführung des Zustands die Fehlerausgabe.

Für den ersten Catcher im Beispiel fügt der Catcher der Eingabe also die Fehlerausgabe als Feld mit dem Namen hinzu, error-info falls es nicht bereits ein Feld mit diesem Namen in der Eingabe gibt. Dann sendet der Catcher die gesamte Eingabe anRecoveryState. Beim zweiten Catcher überschreibt die Fehlerausgabe die Eingabe und der Catcher sendet nur die Fehlerausgabe an. EndState

Anmerkung

Wenn Sie das Feld ResultPath nicht angeben, wird es standardmäßig mit $ ausgefüllt, was die gesamte Eingabe auswählt und so überschreibt.

Wenn ein Status Retry sowohl als auch Catch Felder enthält, verwendet Step Functions zuerst alle geeigneten Retrier. Wenn die Wiederholungsrichtlinie den Fehler nicht beheben kann, wendet Step Functions den passenden Catcher-Übergang an.

Verursacht Payloads und Serviceintegrationen

Ein Catcher gibt eine Zeichenketten-Payload als Ausgabe zurück. Wenn Sie mit Serviceintegrationen wie Amazon Athena oder arbeiten AWS CodeBuild, möchten Sie die Cause Zeichenfolge möglicherweise in konvertieren. JSON Das folgende Beispiel für einen Pass Status mit systemeigenen Funktionen zeigt, wie eine Zeichenfolge in konvertiert wird. Cause JSON

"Handle escaped JSON with JSONtoString": {
  "Type": "Pass",
  "Parameters": {
    "Cause.$": "States.StringToJson($.Cause)"
  },
  "Next": "Pass State with Pass Processing"
},

Beispiele für Zustandsmaschinen mit Retry und Catch

Die in den folgenden Beispielen definierten Zustandsmaschinen setzen die Existenz von zwei Lambda-Funktionen voraus: eine, die immer fehlschlägt, und eine, die lange genug wartet, bis ein in der Zustandsmaschine definierter Timeout eintritt.

Dies ist eine Definition einer Lambda-Funktion von Node.js, die immer fehlschlägt und die Nachricht error zurückgibt. In den folgenden State-Machine-Beispielen wird diese Lambda-Funktion benanntFailFunction. Informationen zum Erstellen einer Lambda-Funktion finden Sie Schritt 1: Erstellen einer Lambda-Funktion im Abschnitt.

exports.handler = (event, context, callback) => {
    callback("error");
};

Dies ist eine Definition einer Lambda-Funktion von Node.js, die 10 Sekunden lang in den Ruhemodus wechselt. In den folgenden State-Machine-Beispielen wird diese Lambda-Funktion benanntsleep10.

Anmerkung

Denken Sie beim Erstellen dieser Lambda-Funktion in der Lambda-Konsole daran, den Timeout-Wert im Abschnitt Erweiterte Einstellungen von 3 Sekunden (Standard) auf 11 Sekunden zu ändern.

exports.handler = (event, context, callback) => {
    setTimeout(function(){
    }, 11000);
};

Behandlung eines Fehlers mithilfe von Retry

Dieser Zustandsautomat verwendet ein Retry-Feld, das eine fehlgeschlagene Funktion erneut versucht und den Fehlernamen HandledError ausgibt. Diese Funktion wird zweimal wiederholt, wobei zwischen den Wiederholungen ein exponentieller Backoff auftritt.

{
   "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function",
   "StartAt": "HelloWorld",
   "States": {
      "HelloWorld": {
         "Type": "Task",
         "Resource": "arn:aws:lambda:us-east-1:123456789012:function:FailFunction",
         "Retry": [ {
            "ErrorEquals": ["HandledError"],
            "IntervalSeconds": 1,
            "MaxAttempts": 2,
            "BackoffRate": 2.0
         } ],
      "End": true
      }
   }
}

Diese Variante verwendet den vordefinierten FehlercodeStates.TaskFailed, der jedem Fehler entspricht, den eine Lambda-Funktion ausgibt.

{
   "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function",
   "StartAt": "HelloWorld",
   "States": {
      "HelloWorld": {
         "Type": "Task",
         "Resource": "arn:aws:lambda:us-east-1:123456789012:function:FailFunction",
         "Retry": [ {
            "ErrorEquals": ["States.TaskFailed"],
            "IntervalSeconds": 1,
            "MaxAttempts": 2,
            "BackoffRate": 2.0
         } ],
         "End": true
      }
   }
}
Anmerkung

Es hat sich bewährt, dass Aufgaben, die auf eine Lambda-Funktion verweisen, Lambda-Serviceausnahmen behandeln sollten. Weitere Informationen finden Sie unter Behandlung für vorübergehende Lambda-Serviceausnahmen hinzufügen.

Behandlung eines Fehlers mit Catch

In diesem Beispiel wird ein Catch-Feld verwendet. Wenn eine Lambda-Funktion einen Fehler ausgibt, fängt sie den Fehler ab und die Zustandsmaschine wechselt in den fallback Status.

{
   "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function",
   "StartAt": "HelloWorld",
   "States": {
      "HelloWorld": {
         "Type": "Task",
         "Resource": "arn:aws:lambda:us-east-1:123456789012:function:FailFunction",
         "Catch": [ {
            "ErrorEquals": ["HandledError"],
            "Next": "fallback"
         } ],
         "End": true
      },
      "fallback": {
         "Type": "Pass",
         "Result": "Hello, AWS Step Functions!",
         "End": true
      }
   }
}

Diese Variante verwendet den vordefinierten FehlercodeStates.TaskFailed, der jedem Fehler entspricht, den eine Lambda-Funktion ausgibt.

{
   "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function",
   "StartAt": "HelloWorld",
   "States": {
      "HelloWorld": {
         "Type": "Task",
         "Resource": "arn:aws:lambda:us-east-1:123456789012:function:FailFunction",
         "Catch": [ {
            "ErrorEquals": ["States.TaskFailed"],
            "Next": "fallback"
         } ],
      "End": true
      },
      "fallback": {
         "Type": "Pass",
         "Result": "Hello, AWS Step Functions!",
         "End": true
      }
   }
}

Behandlung eines Timeouts mithilfe von Retry

Diese Zustandsmaschine verwendet ein Retry Feld, um einen Task Status zu wiederholen, bei dem das Timeout überschritten wurde, basierend auf dem in angegebenen Timeout-Wert. TimeoutSeconds Step Functions wiederholt den Lambda-Funktionsaufruf in diesem Task Zustand zweimal, mit einem exponentiellen Backoff zwischen den Wiederholungen.

{
   "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function",
   "StartAt": "HelloWorld",
   "States": {
      "HelloWorld": {
         "Type": "Task",
         "Resource": "arn:aws:lambda:us-east-1:123456789012:function:sleep10",
         "TimeoutSeconds": 2,
         "Retry": [ {
            "ErrorEquals": ["States.Timeout"],
            "IntervalSeconds": 1,
            "MaxAttempts": 2,
            "BackoffRate": 2.0
         } ],
         "End": true
      }
   }
}

Behandlung eines Timeouts mit Catch

In diesem Beispiel wird ein Catch-Feld verwendet. Wenn ein Timeout aufgetreten ist, wechsel der Zustandsautomat in den Zustand fallback.

{
   "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function",
   "StartAt": "HelloWorld",
   "States": {
      "HelloWorld": {
         "Type": "Task",
         "Resource": "arn:aws:lambda:us-east-1:123456789012:function:sleep10",
         "TimeoutSeconds": 2,
         "Catch": [ {
            "ErrorEquals": ["States.Timeout"],
            "Next": "fallback"
         } ],
         "End": true
      },
      "fallback": {
         "Type": "Pass",
         "Result": "Hello, AWS Step Functions!",
         "End": true
      }
   }
}
Anmerkung

Sie können die Statuseingabe und den Fehler beibehalten, indem Sie ResultPath verwenden. Siehe Wird verwendet ResultPath , um sowohl Fehler als auch Eingaben in eine Catch.