翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

TestState API を使用したステートマシンのテスト

概要:

Step Functions コンソール、、AWSCommand Line Interface (AWS CLI)または SDK の TestState 機能を使用して、サポートされている状態をテストできます。

TestState API は、状態の定義を受け入れて実行します。これにより、ステートマシンを作成したり、既存のステートマシンを更新したりすることなく、ステートをテストできます。以下を指定できます。

TestState API は、状態がアクセスするリソースに必要なIAMアクセス許可を含む必要がある IAMロールを引き受けます。モックを指定すると、ロールの指定はオプションになり、IAMアクセス許可を設定せずにステートマシンロジックをテストできます。ステートに必要なアクセス許可については、「TestState API を使用するための IAM アクセス許可」を参照してください。

トピック

TestState API で検査レベルを使用する

TestState API を使用して状態をテストする場合、テスト結果に表示する詳細の量を指定できます。たとえば、 InputPathや などの入出力データ処理フィルターを使用した場合ResultPath、中間および最終データ処理結果を表示できます。 Step Functionsには、次の検査レベルが用意されています。

これらのレベルはすべて、status および nextState フィールドも返します。status は、ステート実行のステータスを示します。例えば、SUCCEEDED、FAILED、RETRIABLE、および CAUGHT_ERROR などです。nextState は、次に遷移するステートの名前を示します。定義に次のステートを定義していない場合、このフィールドは空の値を返します。

Step Functions コンソールおよび AWS CLI でこれらの検査レベルを使用してステートをテストする方法については、「AWSStep Functions コンソールを使用した状態テスト」および「を使用して状態をテストするAWS CLI」を参照してください。

INFO inspectionLevel

テストが成功すると、このレベルにはステート出力が表示されます。テストが失敗した場合、このレベルにはエラー出力が表示されます。レベルを指定しない場合、デフォルトで Step Functions は [検査レベル] を [INFO] に設定します。

DEBUG inspectionLevel

テストが成功すると、このレベルにはステート出力と入出力データ処理の結果が表示されます。

テストが失敗した場合、このレベルにはエラー出力が表示されます。このレベルには、障害発生時点までの中間データ処理結果が表示されます。例えば、Lambda 関数を呼び出すタスクステートをテストしたとします。タスクステートに、InputPath、パラメータ、Step Functions で ResultPath を使用してステートの出力を指定する、および OutputPath を使用したステートの出力のフィルタリング フィルターを適用したとします。呼び出しが失敗したとします。この場合、DEBUG レベルにはフィルターの適用に基づくデータ処理結果が次の順序で表示されます。

このレベルで利用できる診断情報は、定義したサービス統合や入出力データ処理フローに関連する問題のトラブルシューティングに役立ちます。

TRACE inspectionLevel

Step Functions は HTTP タスクをテストするための [TRACE] レベルを提供します。このレベルでは、Step Functions が行う HTTP リクエストと、HTTPS API が返すレスポンスに関する情報が返されます。レスポンスには、ヘッダーやリクエスト本文などの情報が含まれる場合があります。さらに、このレベルでの入出力データ処理のステート出力と結果も表示できます。

テストが失敗した場合、このレベルにはエラー出力が表示されます。

このレベルは HTTP タスクにのみ適用されます。このレベルを他のステートタイプに使用すると、Step Functions はエラーをスローします。

[検査レベル] を [TRACE] に設定すると、EventBridge 接続に含まれるシークレットも表示できます。そのためには、TestState API で revealSecrets パラメータを true に設定する必要があります。さらに、TestState API を呼び出す IAM ユーザーに states:RevealSecrets アクションのアクセス許可があることを確認する必要があります。states:RevealSecrets アクセス許可を付与する IAM ポリシーの例については、「TestState API を使用するための IAM アクセス許可」を参照してください。このアクセス許可がない場合、Step Functions はアクセス拒否エラーをスローします。

revealSecrets パラメータを false に設定すると、Step Functions はHTTP リクエストとレスポンスのデータに含まれるすべてのシークレットを省略します。モックが有効になっていrevealSecretsる場合は、 を使用できないことに注意してください。TestState API リクエストで revealSecretsとモックの両方を指定すると、 は検証例外Step Functionsを返します。

TestState API を使用するための IAM アクセス許可

TestState API を呼び出すIAMユーザーには、states:TestStateアクションを実行するアクセス許可が必要です。モックを使用しない場合、IAMユーザーは実行ロールを に渡すiam:PassRoleアクションを実行するアクセス許可も持っている必要がありますStep Functions。さらに、 revealSecretsパラメータを に設定した場合true、IAMユーザーは states:RevealSecretsアクションを実行するアクセス許可を持っている必要があります。このアクセス許可がない場合、Step Functions はアクセス拒否エラーをスローします。

TestState API リクエストでモックを指定すると、実行ロールを指定せずにステートマシンロジックをテストできることに注意してください (詳細については、「サービス統合のモッキング」を参照してください）。モックを使用していない場合は、状態がアクセスするリソースに必要なアクセス許可を含む実行ロールを指定する必要があります。ステートが必要とするアクセス許可については、「実行ロールの管理」を参照してください。

AWSStep Functions コンソールを使用した状態テスト

コンソールでステートをテストし、ステートの出力または入出力データの処理フローを確認できます。HTTP タスクでは、未加工の HTTP リクエストとレスポンスをテストできます。

を使用して状態をテストするAWS CLI

で TestState API を使用して状態をテストできますAWS CLI。この API はステートの定義を受け入れて実行します。

ステートごとに、テスト結果に表示したい詳細の量を指定できます。これらの詳細から、入出力データ処理結果や HTTP リクエスト/レスポンス情報など、ステートの実行に関する追加情報が得られます。以下の例は、TestState API に指定できるさまざまな検査レベルを示しています。

このセクションには、Step Functions が AWS CLI で提供するさまざまな検査レベルの使用方法を示す次の例が含まれています。

例 1: INFO inspectionLevel を使用して Choice ステートをテストする

の INFO inspectionLevel を使用して状態をテストするにはAWS CLI、次の例に示すように test-state コマンドを実行します。

aws stepfunctions test-state \
    --definition '{"Type": "Choice", "Choices": [{"Variable": "$.number", "NumericEquals": 1, "Next": "Equals 1"}, {"Variable": "$.number", "NumericEquals": 2, "Next": "Equals 2"}], "Default": "No Match"}' \
    --role-arn arn:aws:iam::account-id:role/myRole \
    --input '{"number": 2}'

この例では、Choice ステートを使用して、指定した数値入力に基づいてステートの実行パスを決定します。レベルを設定しない場合、 Step Functions はデフォルトで inspectionLevel を INFO に設定します。

Step Functions は次の出力を返します。

{
    "output": "{\"number\": 2}",
    "nextState": "Equals 2",
    "status": "SUCCEEDED"
}

例 2: DEBUG InspectionLevel を使用して Pass ステートの入出力データ処理をデバッグする

の DEBUG inspectionLevel を使用して状態をテストするにはAWS CLI、次の例に示すように test-state コマンドを実行します。

aws stepfunctions test-state \
    --definition '{"Type": "Pass", "InputPath": "$.payload", "Parameters": {"data": 1}, "ResultPath": "$.result", "OutputPath": "$.result.data", "Next": "Another State"}' \
    --role-arn arn:aws:iam::account-id:role/myRole \
    --input '{"payload": {"foo": "bar"}}' \
    --inspection-level DEBUG

この例では、Pass ワークフロー状態 ステートを使用して、Step Functions が入出力データ処理フィルターを使用して入力 JSON データをフィルタリングおよび操作する方法を示しています。この例では、InputPath、パラメータ、Step Functions で ResultPath を使用してステートの出力を指定する、および OutputPath を使用したステートの出力のフィルタリング フィルターを使用しています。

Step Functions は次の出力を返します。

{
    "output": "1",
    "inspectionData": {
        "input": "{\"payload\": {\"foo\": \"bar\"}}",
        "afterInputPath": "{\"foo\":\"bar\"}",
        "afterParameters": "{\"data\":1}",
        "afterResultSelector": "{\"data\":1}",
        "afterResultPath": "{\"payload\":{\"foo\":\"bar\"},\"result\":{\"data\":1}}"
    },
    "nextState": "Another State",
    "status": "SUCCEEDED"
}

例 3: TRACE inspectionLevel と revealSecrets を使用して、HTTPS API に送信された HTTP リクエストを検査する

TRACE inspectionLevel と の revealSecrets パラメータを使用して HTTP タスクをテストするにはAWS CLI、次の例に示すように test-state コマンドを実行します。

aws stepfunctions test-state \
    --definition '{"Type": "Task", "Resource": "arn:aws:states:::http:invoke", "Parameters": {"Method": "GET", "Authentication": {"ConnectionArn": "arn:aws:events:region:account-id:connection/MyConnection/0000000-0000-0000-0000-000000000000"}, "ApiEndpoint": "https://httpbin.org/get", "Headers": {"definitionHeader": "h1"}, "RequestBody": {"message": "Hello from Step Functions!"}, "QueryParameters": {"queryParam": "q1"}}, "End": true}' \
    --role-arn arn:aws:iam::account-id:role/myRole \
    --inspection-level TRACE \
    --reveal-secrets

この例では、HTTP タスクが指定された HTTPS API である https://httpbin.org/ を呼び出しているかどうかをテストします。API コールの HTTP リクエストとレスポンスデータも表示されます。

Step Functions は、現在のドキュメントの元の例のような出力を返します。

例 4: jq ユーティリティを使用して TestState API が返すレスポンスをフィルタリングして印刷する

TestState API は、JSON データをエスケープされた文字列としてレスポンスで返します。次の AWS CLI 例では、例 3 を拡張し、jq ユーティリティを使用して TestState API が返す HTTP レスポンスをフィルタリングし、人間が読める形式で出力します。jq およびインストール手順の詳細については、GitHub の「jq」を参照してください。

aws stepfunctions test-state \
    --definition '{"Type": "Task", "Resource": "arn:aws:states:::http:invoke", "Parameters": {"Method": "GET", "Authentication": {"ConnectionArn": "arn:aws:events:region:account-id:connection/MyConnection/0000000-0000-0000-0000-000000000000"}, "ApiEndpoint": "https://httpbin.org/get", "Headers": {"definitionHeader": "h1"}, "RequestBody": {"message": "Hello from Step Functions!"}, "QueryParameters": {"queryParam": "q1"}}, "End": true}' \
    --role-arn arn:aws:iam::account-id:role/myRole \
    --inspection-level TRACE \
    --reveal-secrets \
    | jq '.inspectionData.response.body | fromjson'

次の例は、人間が読める形式で返される出力を示しています。

{
  "args": {
    "QueryParam1": "QueryParamValue1",
    "queryParam": "q1"
  },
  "headers": {
    "Authorization": "Basic XXXXXXXX",
    "Content-Type": "application/json; charset=UTF-8",
    "Customheader1": "CustomHeaderValue1",
    "Definitionheader": "h1",
    "Host": "httpbin.org",
    "Range": "bytes=0-262144",
    "Transfer-Encoding": "chunked",
    "User-Agent": "Amazon|StepFunctions|HttpInvoke|region",
    "X-Amzn-Trace-Id": "Root=1-0000000-0000-0000-0000-000000000000"
  },
  "origin": "12.34.567.891",
  "url": "https://httpbin.org/get?queryParam=q1&QueryParam1=QueryParamValue1"
}

入力データと出力データフローのテストとデバッグ

TestState API は、ワークフローを移動するデータのテストとデバッグに役立ちます。このセクションでは、いくつかの重要な概念を示し、この目的で TestState を使用する方法について説明します。

主要なコンセプト

Step Functions では、ステートマシンのステートを通過する JSON データをフィルタリングして操作するプロセスを入出力処理と呼びます。この仕組みについては、「Step Functions の入力および出力処理」を参照してください。

Amazon States Language (ASL) のすべてのステートタイプ (Task、Parallel、Map、Pass、Wait、Choice、Succeed、Fail) は、それらを通過する JSON データをフィルタリングし、操作するための共通のフィールドセットを共有しています。これらのフィールドは、InputPath、パラメータ、ResultSelector、Step Functions で ResultPath を使用してステートの出力を指定する、および OutputPath を使用したステートの出力のフィルタリング です。各フィールドのサポートはステートによって異なります。実行時には、Step Functions は各フィールドを特定の順序で適用します。以下の図は、これらのフィールドがタスクステート内のデータに適用される順序を示しています。

以下のリストは、図に示されている入力処理フィールドと出力処理フィールドの適用順序を示しています。

これらの入力処理フィールドと出力処理フィールドはオプションです。状態定義でこれらのフィールドを使用しない場合、タスクは raw 状態入力を消費し、タスク結果を状態出力として返します。

TestState を使用して入出力処理を検査する

TestState API を呼び出して inspectionLevel パラメータを DEBUG に設定すると、API レスポンスには inspectionData というオブジェクトが含まれます。このオブジェクトには、実行時にステート内でデータがどのようにフィルタリングまたは操作されたかを調べるのに役立つフィールドが含まれています。次の例は、inspectionData オブジェクトのタスクステートを示しています。

"inspectionData":   {
  "input": string, 
  "afterInputPath": string, 
  "afterParameters": string, 
  "result": string, 
  "afterResultSelector": string, 
  "afterResultPath": string,
  "output": string 
}

この例では、after プレフィックスを含む各フィールドには、特定のフィールドが適用された後のデータが表示されます。例えば、afterInputPath は InputPath フィールドを適用して未加工のステート入力をフィルタリングしたときの効果を示しています。以下の図は、各 ASL 定義フィールドを inspectionData オブジェクト内の対応するフィールドにマッピングしています。

TestState API を使用して入出力処理をデバッグする例については、以下を参照してください。

特にマップ状態の場合、 inspectionLevelを に設定するとDEBUG、inspectionDataオブジェクトには、マップ状態が項目を抽出および変換する方法を検査するのに役立つ追加のフィールドが含まれます。これらのフィールドの詳細については、「マップ状態検査データについて」セクションを参照してください。

マップ状態検査データについて

を inspectionLevelに設定して Map 状態をテストするとDEBUG、TestState API レスポンスには、Map 状態がデータを処理する方法を示す追加のフィールドが inspectionData オブジェクトに含まれます。

これらのフィールドを使用すると、デプロイ前にマップ状態のデータ変換と障害耐性設定が正しく機能することを検証できます。

TestState API でテストおよびアサートできる内容

TestState API を使用すると、ステートマシンの包括的なユニットテストを作成できます。ステートマシンロジックの複数の側面でアサートできます。これには、以下が含まれます。

エラー処理: 適用するキャッチまたは再試行

エラーをモックするときは、TestState API を使用して、どのエラーハンドラーがアクティブ化されるかを確認できます。

キャッチブロックの場合、以下をアサートできます。

再試行ブロックでは、以下をアサートできます。

データ変換: 入出力処理

TestState API を使用すると、処理の各段階で状態データの変換方法を検証できます。

以下に対してアサートできます。

マップ状態変換: ItemSelector、ItemsPath、ItemBatcher、ItemsPointer

Map 状態の場合、TestState API を使用して、項目がどのように抽出および変換されるかを確認できます。

以下に対してアサートできます。

マップ状態の障害しきい値: States.ExceedToleratedFailureThreshold のテスト

特定の回数の失敗した反復が許容される失敗しきい値をトリガーするかどうかをテストします。

以下に対してアサートできます。

マップ状態と並列状態のエラー伝達

マップ状態または並列状態内で状態をテストすると、エラーは実際の実行時と同様に親状態エラーハンドラーに伝播されます。

errorCausedByState を使用したエラーソースの指定

マップ状態または並列状態のエラーをモックするときは、 stateConfiguration.errorCausedByStateパラメータを使用してエラーの原因となったサブ状態を指定する必要があります。これは、 などのワイルドカードエラーをテストするときに特に重要ですStates.TaskFailed。 States.TaskFailedは、タスク状態の障害に適用されるワイルドカードエラーです。マップ状態または並列状態がこのエラーをどのように処理するかをテストするには、それをスローした特定のサブ状態を特定する必要があります。以下の例を参照してください。

aws stepfunctions test-state \
  --definition '{...Map or Parallel state definition...}' \
  --input '[...]' \
  --state-configuration '{"errorCausedByState": "ProcessItem"}' \
  --mock '{"errorOutput": {"error": "States.TaskFailed", "cause": "Task execution failed"}}'

この例では、 は、Map/Parallel ワークフロー内のProcessItem」状態がエラーをスローしたことを TestState errorCausedByStateに伝えます。親マップ/並列状態のキャッチハンドラーまたは再試行ハンドラーは、実際の実行時と同じようにエラーを処理します。レスポンスの nextStateフィールドには、エラーを検出したエラーハンドラーが表示されます。以下に対してアサートできます。

サービス統合のモッキング

TestState API は、サービス統合の結果のモックをサポートしているため、実際のAWSサービスを呼び出すことなくステートマシンロジックをテストできます。

モックを使用するタイミング

モッキングは、次の場合に便利です。

モックを指定すると、 roleArnパラメータはオプションになり、アクセス許可関連の問題に対処することなく、ステートマシン定義のテストに集中できます。

基本的なモック構文

サービス統合結果をモックするには:

aws stepfunctions test-state \
  --definition '{
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Arguments": {
      "FunctionName": "MyFunction",
      "Payload.$": "$"
    },
    "End": true
  }' \
  --input '{"key": "value"}' \
  --mock '{"result": "{\"Payload\": {\"statusCode\": 200, \"body\": \"Success\"}}"}'

エラーをモックするには:

aws stepfunctions test-state \
  --definition '{
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Arguments": {...},
    "End": true
  }' \
  --input '{"key": "value"}' \
  --mock '{"errorOutput": {"error": "Lambda.ServiceException", "cause": "Service unavailable"}}'

モック検証モード

TestState API は、モックレスポンスをAWSサービス API モデルと照合して検証し、正確性を確認します。検証動作は、 fieldValidationModeパラメータを使用して制御できます。

検証モードの例:

aws stepfunctions test-state \
  --definition '{
    "Type": "Task",
    "Resource": "arn:aws:states:::dynamodb:putItem",
    "Parameters": {...},
    "End": true
  }' \
  --input '{"key": "value"}' \
  --mock '{"fieldValidationMode": "STRICT", "result": "{\"Attributes\": {...}}"}'

マップと並列状態のテスト

TestState API は、モックが指定されている場合のマップ状態と並列状態のテストをサポートしています。これにより、これらのフロー状態の入出力処理をテストできます。

マップ状態テストについて

TestState API を使用してマップ状態をテストする場合、内部で反復を実行せずにマップ状態の入力および出力処理をテストします。このアプローチにより、以下をテストできます。

ItemProcessor (各項目を処理する状態) 内で何が起こるかをテストしていません。

マップ状態のテスト

Map 状態をテストする場合、モック結果は Map 状態全体の出力を表す必要があります。モック結果は、マップ状態設定に応じて有効な JSON 配列または JSON オブジェクトである必要があります。以下の例を参照してください。

aws stepfunctions test-state \
  --definition '{
    "Type": "Map",
    "ItemsPath": "$.items",
    "ItemSelector": {
      "value.$": "$$.Map.Item.Value",
      "index.$": "$$.Map.Item.Index"
    },
    "ItemProcessor": {
      "ProcessorConfig": {"Mode": "INLINE"},
      "StartAt": "ProcessItem",
      "States": {
        "ProcessItem": {
          "Type": "Task",
          "Resource": "arn:aws:states:::lambda:invoke",
          "End": true
        }
      }
    },
    "End": true
  }' \
  --input '{"items": [1, 2, 3, 4, 5]}' \
  --mock '{"result": "[10, 20, 30, 40, 50]"}' \
  --inspection-level DEBUG

分散マップの状態のテスト

分散マップの状態は、インラインマップの状態と同様にテストされます。Map が ItemReader を使用して S3 から読み取る場合は、データを (S3 から既に読み取られているかのように) 入力に直接入力します。例えば、次のようになります。

aws stepfunctions test-state \
  --definition '{
    "Type": "Map",
    "ItemReader": {
      "Resource": "arn:aws:states:::s3:getObject",
      "Parameters": {
        "Bucket": "my-bucket",
        "Key": "orders.json"
      }
    },
    "ItemsPath": "$.orders",
    "ItemProcessor": {
      "ProcessorConfig": {"Mode": "DISTRIBUTED"},
      ...
    },
    "ToleratedFailureCount": 5,
    "End": true
  }' \
  --input '{
    "orders": [
      {"orderId": "123"},
      {"orderId": "456"},
      {"orderId": "789"}
    ]
  }' \
  --mock '{"result": "..."}'

自動コンテキストポピュレーション

context パラメータを指定せずにマップ状態 ( stateNameパラメータを使用) の状態をテストすると、TestState は Context オブジェクトにデフォルト値を自動的に入力します。これには、次のようなマップ固有のコンテキストフィールドが含まれます。

並列状態のテスト

並列状態をテストする場合、モック結果はブランチごとに 1 つの要素を持つ JSON 配列で、定義に表示されるのと同じ順序である必要があります。

Activity、.sync、.waitForTaskToken の状態のテスト

TestState API は、モックが指定されている場合、アクティビティ状態、.sync サービス統合パターン、.waitForTaskToken パターンのテストをサポートしています。モックがない場合、TestState API を介してこれらの状態を呼び出すと、検証例外が返されます。

ステートマシン定義の反復処理

TestState API に完全なステートマシン定義を指定し、 stateNameパラメータを使用してテストする状態を指定できます。これにより、ステートマシン全体のコンテキスト内で特定の状態をテストできます。1 つのテストから次のテストへの入力として、出力と nextState を使用してテストを連鎖させることもできます。これにより、ステートマシン内の部分的または完全な実行パスをテストできます。

TestState API でのコンテキストフィールドの使用

context パラメータを使用すると、通常実行中に入力されるコンテキストオブジェクトの値を指定できます。これは、実行 ID、状態名、入力時刻などのコンテキスト値を参照する状態をテストするのに役立ちます。以下の例は、TestState API コールで Context オブジェクトを使用する方法を示しています。

aws stepfunctions test-state \
  --definition '{
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Arguments": {
      "FunctionName": "MyFunction",
      "Payload": {
        "executionId.$": "$$.Execution.Id",
        "stateName.$": "$$.State.Name",
        "enteredTime.$": "$$.State.EnteredTime"
      }
    },
    "End": true
  }' \
  --input '{"data": "value"}' \
  --context '{
    "Execution": {
      "Id": "arn:aws:states:us-east-1:123456789012:execution:MyStateMachine:test-exec-123",
      "Name": "test-exec-123",
      "StartTime": "2024-01-01T10:00:00.000Z"
    },
    "State": {
      "Name": "ProcessData",
      "EnteredTime": "2024-01-01T10:00:05.000Z"
    }
  }' \
  --mock '{"result": "{\"status\": \"success\"}"}'

再試行とエラー処理のテスト

TestState API では、再試行シナリオをシミュレートし、再試行とモックエラーを指定してエラー処理ロジックをテストできます。

再試行のシミュレート

aws stepfunctions test-state \
  --definition '{
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Arguments": {...},
    "Retry": [{
      "ErrorEquals": ["Lambda.ServiceException"],
      "IntervalSeconds": 2,
      "MaxAttempts": 3,
      "BackoffRate": 2.0
    }],
    "End": true
  }' \
  --input '{"data": "value"}' \
  --state-configuration '{"retrierRetryCount": 1}' \
  --mock '{"errorOutput": {"error": "Lambda.ServiceException", "cause": "Service error"}}' \
  --inspection-level DEBUG

レスポンスには inspectionData にエラーの詳細が含まれます。

{
  "status": "RETRIABLE",
  "inspectionData": {
    "errorDetails": {
      "retryBackoffIntervalSeconds": 4,
      "retryIndex": 0
    }
  }
}

このレスポンスは以下を示します。

キャッチハンドラーのテスト

エラーがモックされ、Catch ハンドラーに一致すると、TestState API レスポンスの nextStateフィールドは、エラーを処理する状態を示します。以下の例では、次のようになります。

以下の特定の TestState API リクエストの場合、

aws stepfunctions test-state \
  --definition '{
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Arguments": {...},
    "Catch": [{
      "ErrorEquals": ["Lambda.TooManyRequestsException"],
      "ResultPath": "$.error",
      "Next": "HandleThrottling"
    }],
    "Next": "Success"
  }' \
  --input '{"data": "value"}' \
  --mock '{"errorOutput": {"error": "Lambda.TooManyRequestsException", "cause": "Rate exceeded"}}' \
  --inspection-level DEBUG

予想される API レスポンスは次のとおりです。

{
  "status": "CAUGHT_ERROR",
  "nextState": "HandleThrottling",
  "error": "Lambda.TooManyRequestsException",
  "cause": "Rate exceeded",
  "output": "{\"data\": \"value\", \"error\": {\"Error\": \"Lambda.TooManyRequestsException\", \"Cause\": \"Rate exceeded\"}}",
  "inspectionData": {
    "errorDetails": {
      "catchIndex": 0
    }
  }
}

このレスポンスは、以下を示します。

コンテキストオブジェクトの RetryCount 値を増やすことで、すべての再試行回数が枯渇したときに何が起こるかをテストすることもできます。