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.
Umgang mit Fehlern 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, unter anderem aus den folgenden:
-
Probleme mit der Definition von Zustandsmaschinen, z. B. ein Auswahlstatus ohne passende Regel
-
Fehler bei Aufgaben, z. B. eine Ausnahme in einer AWS Lambda Funktion
-
Vorübergehende Probleme — wie Netzwerkpartitionsereignisse
Wenn ein Status einen Fehler meldet, schlägt Step Functions standardmäßig die gesamte State-Machine-Ausführung fehl. Step Functions bietet auch erweiterte Funktionen zur Fehlerbehandlung. Sie können Ihre Zustandsmaschine so einrichten, dass sie Fehler abfängt, fehlgeschlagene Zustände wiederholt und Fehlerbehandlungsprotokolle ordnungsgemäß implementiert.
Step Functions Functions-Catcher sind für den Status Task, Parallel und Map verfügbar, jedoch nicht für Fehler bei der Ausführung von Zustandsmaschinen auf oberster Ebene. Um Ausführungen zu verarbeiten, von denen Sie erwarten, dass sie fehlschlagen könnten, kann Ihr Aufrufer den Fehler behandeln, oder Sie können diese Ausführungen in untergeordneten Workflows verschachteln, um Fehler in Ihrem übergeordneten Workflow abzufangen. Alternativ können Sie sich dafür entscheiden, TIMED_OUT
Ereignisse aus Standard-Workflows mit einem EventBridge Bus abzuhören und eine Aktion zur Behandlung der fehlgeschlagenen Ausführung aufzurufen.
Praktische Beispiele für den Umgang mit Fehlern
Ein Beispiel für einen Workflow, der Fehlerbehandlung beinhaltet, finden Sie im Behandlung von Fehlerbedingungen in einer Step Functions Functions-Zustandsmaschine Tutorial in diesem Handbuch und unter Fehlerbehandlung
Namen der Fehler
Step Functions identifiziert Fehler mithilfe von Zeichenketten, 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.
Zustände können Fehler mit anderen Namen melden. Die Fehlernamen dürfen jedoch nicht mit dem States.
Präfix beginnen.
Stellen Sie sicher, dass Ihr Produktionscode AWS Lambda Serviceausnahmen (Lambda.ServiceException
undLambda.SdkClientException
) verarbeiten kann. Weitere Informationen finden Sie unter Bewährte Methoden. Behandeln Sie vorübergehende Lambda-Serviceausnahmen
-
States.ALL
-
Ein Platzhalter, der mit jedem bekannten Fehlernamen übereinstimmt.
Der
States.ALL
Fehlertyp muss alleine in a vorkommenCatcher
und kann denStates.DataLimitExceeded
Terminalfehler oder dieRuntime
Fehlertypen nicht abfangen.Weitere Informationen erhalten Sie unter States.DataLimitExceeded und States.Runtime.
-
States.DataLimitExceeded
-
Ein Terminalfehler, der nicht durch den
States.ALL
Fehlertyp abgefangen werden kann.Aufgrund der folgenden Bedingungen gemeldet:
-
Die Ausgabe eines Connectors übersteigt das Kontingent für die Payload-Größe.
-
Die Ausgabe eines Zustands ist größer als das Kontingent für die Nutzdatengröße.
-
Nach der
Parameters
Verarbeitung ist die Eingabe eines Zustands größer als das Payload-Größenkontingent.
Weitere Informationen zu Kontingenten finden Sie unterStep Functions Servicekontingenten.
-
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 derHeartbeatSeconds
Wert war, keinen Heartbeat senden.HeartbeatTimeout
ist in denRetry
FeldernCatch
und verfügbar. -
States.Http.Socket
-
Tritt auf, wenn bei einer HTTP-Aufgabe nach 60 Sekunden eine Zeitüberschreitung eintritt. Siehe Kontingente im Zusammenhang mit HTTP-Tasks.
States.ItemReaderFailed
Ein
Map
Status ist fehlgeschlagen, weil er nicht aus der imItemReader
Feld angegebenen Elementquelle lesen konnte. Weitere Informationen finden Sie unterItemReader (Karte)
.-
States.Permissions
-
Ein
Task
Status schlug fehl, weil er nicht über ausreichende Rechte verfügte, um den angegebenen Code auszuführen. States.ResultWriterFailed
Ein
Map
Status ist fehlgeschlagen, weil er keine Ergebnisse in das imResultWriter
Feld angegebene Ziel schreiben konnte. Weitere Informationen finden Sie unterResultWriter (Karte)
.States.Runtime
-
Eine Ausführung ist aufgrund einer Ausnahme fehlgeschlagen, die nicht verarbeitet werden konnte. Oft werden diese durch Laufzeitfehler verursacht, z. B. durch den Versuch,
InputPath
oderOutputPath
auf eine JSON-Nutzlast gleich Null anzuwenden. EinStates.Runtime
Fehler kann nicht behoben werden und führt immer dazu, dass die Ausführung fehlschlägt. Ein erneuter Versuch oder ein catch OnStates.ALL
deckt keineStates.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
-
Wird gemeldet, wenn ein
Task
Status länger als derTimeoutSeconds
Wert ist oder wenn für einen Zeitraum, der länger als der Wert ist, kein Heartbeat gesendet wurde.HeartbeatSeconds
Wenn ein verschachtelter Zustandsmaschine einen auslöst
States.Timeout
, erhält der übergeordnete Computer eine Fehlermeldung.States.TaskedFailed
Ein
States.Timeout
Fehler wird auch gemeldet, wenn die Ausführung einer gesamten Zustandsmaschine länger dauert als der angegebeneTimeoutSeconds
Wert.
Anmerkung
Unbehandelte Fehler in Lambda-Laufzeiten wurden in der Vergangenheit nur als gemeldet. Lambda.Unknown
In neueren Laufzeiten werden Timeouts wie Sandbox.Timedout
in der Fehlerausgabe gemeldet.
Wenn Lambda die maximale Anzahl von Aufrufen überschreitet, wird der gemeldete Fehler angezeigt. Lambda.TooManyRequestsException
Stimmt aufLambda.Unknown
, und abSandbox.Timedout
, States.TaskFailed
um mögliche Fehler zu behandeln. Sie können es auch verwendenStates.ALL
, aber es muss alleine und am Ende der Liste stehen.
Weitere Informationen zu Lambda Handled
und Unhandled
Fehlern finden Sie FunctionError
im AWS Lambda Developer Guide.
Erneuter Versuch nach einem Fehler
Task
Parallel
, 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 Verhalten von Ausführungen wiederholen redriven in State-Machine-Ausführungen mit redrive In-Step-Funktionen neu starten.
Ein Retrier enthält die folgenden Felder:
-
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 (
1
standardmäßig).IntervalSeconds
hat 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 von0
gibt an, dass der Fehler nie erneut versucht wird.MaxAttempts
hat 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 derBackoffRate
-Wert um2.0
.Nehmen wir zum Beispiel an, Ihr Wert
IntervalSeconds
ist 3, ist 3 undMaxAttempts
ist 2.BackoffRate
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
oderNONE
als ihre Werte. Der Standardwert istNONE
.Nehmen wir zum Beispiel an, Sie haben den Wert
MaxAttempts
als 3,IntervalSeconds
als 2 undBackoffRate
als 2 festgelegt. Der erste Wiederholungsversuch erfolgt zwei Sekunden nach Auftreten des Fehlers. Der zweite Wiederholungsversuch erfolgt vier Sekunden nach dem ersten Wiederholungsversuch und der dritte Wiederholungsversuch acht Sekunden nach dem zweiten Wiederholungsversuch. Wenn Sie denJitterStrategy
Wert als festlegenFULL
, wird das erste Wiederholungsintervall zufällig zwischen 0 und 2 Sekunden, das zweite Wiederholungsintervall zufällig zwischen 0 und 4 Sekunden und das dritte Wiederholungsintervall zufällig zwischen 0 und 8 Sekunden.
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
Feldbeispiele erneut versuchen
Dieser Abschnitt enthält die folgenden Retry
Feldbeispiele.
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 finden nach einer Wartezeit fünf Sekunden nach dem vorherigen Wiederholungsversuch statt, da die maximale Wartezeit von MaxDelaySeconds
festgelegt ist.
"Retry": [ {
"ErrorEquals": [ "States.Timeout" ],
"IntervalSeconds": 3,
"MaxAttempts": 3,
"BackoffRate":2,
"MaxDelaySeconds": 5,
"JitterStrategy": "FULL"
} ]
Ohne MaxDelaySeconds
würde der zweite Wiederholungsversuch sechs Sekunden nach dem ersten Versuch stattfinden, und der dritte Wiederholungsversuch würde 12 Sekunden nach dem zweiten Versuch stattfinden.
Beispiel 3 — Alle Fehler mit Ausnahme von 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: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"
} ]
}
Diese Aufgabe schlägt viermal hintereinander fehl und gibt die folgenden Fehlernamen aus:ErrorA
, ErrorB
ErrorC
, 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 das Maximum von zwei Wiederholungen (
MaxAttempts
) erreicht. Daher schlägt dieser Retrier fehl und die Ausführung leitet den Workflow über das Feld in denZ
Status um.Catch
Fallback-Zustände
Task
, Map
und Parallel
Staaten können jeweils ein Catch
benanntes Feld haben. 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
(JSONPath, Fakultativ) -
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
Im folgenden Beispiel wechselt ein Catch
-Feld in den Zustand namens RecoveryState
, wenn eine Lambda-Funktion eine nicht behandelte 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"
} ]
Wie viele Fehler kann ein Catcher catch?
Jeder Catcher kann mehrere Fehler angeben, die behandelt werden sollen.
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.
Im vorherigen JSONPath Beispiel enthält der erste Catcher ein ResultPath
Feld. Dies funktioniert ähnlich wie ein ResultPath
-Feld im obersten Level eines Zustands, wodurch sich zwei Möglichkeiten ergeben:
-
Überschreiben Sie anhand der Ergebnisse der Ausführung dieses Zustands entweder die gesamte Eingabe des Zustands oder einen Teil davon.
-
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 anEndState
.
Wenn Sie bei JSONPath Workflows das ResultPath
Feld nicht angeben, wird standardmäßig der Wert verwendet$
, wodurch die gesamte Eingabe ausgewählt und überschrieben wird.
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 JSON konvertieren. Das folgende Beispiel für einen Pass
Status mit systemeigenen Funktionen zeigt, wie eine Cause
Zeichenfolge in JSON konvertiert wird.
"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
.
exports.handler = (event, context, callback) => {
setTimeout(function(){
}, 11000);
};
Timeout-Einstellungen für die Funktion
Denken Sie beim Erstellen der Lambda-Funktion für die Beispiele daran, den Timeout
Wert in den erweiterten Einstellungen auf 11 Sekunden festzulegen.
Behandlung eines Fehlers mit 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 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
}
}
}
Diese Variante verwendet den vordefinierten FehlercodeStates.TaskFailed
, der jedem Fehler entspricht, den eine Lambda-Funktion ausgibt.
{
"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
}
}
}
Bewährte Methoden für den Umgang mit Lambda-Ausnahmen
Aufgaben, die auf eine Lambda-Funktion verweisen, sollten Lambda-Serviceausnahmen behandeln. Weitere Informationen finden Sie unter Behandeln Sie vorübergehende Lambda-Serviceausnahmen Bewährte Methoden.
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": "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
}
}
}
Diese Variante verwendet den vordefinierten FehlercodeStates.TaskFailed
, der jedem Fehler entspricht, den eine Lambda-Funktion ausgibt.
{
"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
}
}
}
Behandlung eines Timeouts mithilfe von Retry
Diese Zustandsmaschine verwendet ein Retry
Feld, um einen Task
Status, bei dem das Timeout überschritten wurde, erneut zu versuchen, 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": "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
}
}
}
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": "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
}
}
}
Beibehaltung von Statuseingaben und Fehlern in JSONPath
JSONPathIn können Sie die Statuseingabe und den Fehler beibehalten, indem Sie ResultPath
Siehe Wird verwendet ResultPath , um sowohl Fehler als auch Eingaben in eine Catch.