Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Probar máquinas de estado con TestState API

Descripción general de

Puede probar un estado compatible mediante la TestState función de la Step Functions consola o AWSCommand Line Interface (AWS CLI) el SDK.

La TestStateAPI acepta la definición de un estado y la ejecuta. Le permite probar un estado sin crear una máquina de estados ni actualizar una máquina de estados existente. Puede proporcionar:

La TestState API asume una IAM función que debe contener los IAM permisos necesarios para los recursos a los que accede su estado. Cuando especificas un simulacro, especificar el rol pasa a ser opcional, lo que te permite probar la lógica de la máquina de estados sin configurar IAM los permisos. Para obtener información acerca de los permisos que podría necesitar un estado, consulte IAMpermisos para usar la TestState API.

Temas

Uso de niveles de inspección en la TestState API

Al probar un estado mediante la TestStateAPI, puede especificar la cantidad de detalles que desea ver en los resultados de la prueba. Por ejemplo, si has utilizado filtros de procesamiento de datos de entrada y salida, como InputPatho ResultPath, puedes ver los resultados del procesamiento de datos intermedio y final. Step Functionsproporciona los siguientes niveles de inspección:

Todos estos niveles también devuelven los campos status y nextState. status indica el estado de la ejecución de estado. Por ejemplo, SUCCEEDED, FAILED, RETRIABLE y CAUGHT_ERROR. nextState indica el nombre del siguiente estado al que se realizará la transición. Si no ha definido un estado siguiente en la definición, este campo devuelve un valor vacío.

Para obtener información sobre cómo probar un estado mediante estos niveles de inspección en la consola de Step Functions y AWS CLI, consulte Prueba de un estado mediante la consola AWS Step Functions y Probar un estado usando AWS CLI.

INFO inspectionLevel

Si la prueba se realiza correctamente, este nivel muestra la salida de estado. Si la prueba falla, este nivel muestra la salida de error. De forma predeterminada, Step Functions establece Nivel de inspección en INFO si no se especifica ningún nivel.

DEBUG inspectionLevel

Si la prueba se realiza correctamente, este nivel muestra la salida de estado y el resultado del procesamiento de datos de entrada y salida.

Si la prueba falla, este nivel muestra la salida de error. Este nivel muestra los resultados intermedios del procesamiento de datos hasta el punto de error. Por ejemplo, supongamos que probó un estado Tarea que invoca una función de Lambda. Supongamos que había aplicado los filtros InputPath, Parameters, Especificación de la salida de estado mediante ResultPath en Step Functions y Filtrado de la salida de estado mediante OutputPath al estado Tarea. Supongamos que la invocación ha producido error. En este caso, el nivel DEBUG muestra los resultados del procesamiento de datos en función de la aplicación de los filtros en el siguiente orden:

La información de diagnóstico disponible en este nivel puede ayudar a solucionar problemas relacionados con un flujo de integración de servicios o de procesamiento de datos de entrada y salida que haya definido.

TRACE inspectionLevel

Step Functions proporciona el nivel TRACE para probar una Tarea HTTP. Este nivel devuelve información sobre la solicitud HTTP que Step Functions realiza y la respuesta que devuelve una API de HTTPS. La respuesta puede contener información, como los encabezados y el cuerpo de la solicitud. Además, puede ver la salida del estado y el resultado del procesamiento de datos de entrada y salida en este nivel.

Si la prueba falla, este nivel muestra la salida de error.

Este nivel solo es aplicable para una tarea HTTP. Step Functions presenta un error si utiliza este nivel para otros tipos de estado.

Al establecer el nivel de inspección en TRACE, también puede ver los secretos incluidos en la EventBridge conexión. Para ello, debe configurar el revealSecrets parámetro true en la TestStateAPI. Además, debes asegurarte de que el IAM usuario que llama a la TestState API tiene permiso para realizar la states:RevealSecrets acción. Para ver una política de IAM de ejemplo que establece el permiso states:RevealSecrets, consulte IAMpermisos para usar la TestState API. Sin este permiso, Step Functions produce un error de acceso denegado.

Si establece el parámetro revealSecrets en false, Step Functions omite todos los secretos de los datos de solicitud y respuesta HTTP. Ten en cuenta que no puedes utilizarla revealSecrets cuando la simulación está habilitada. Si especificas ambos elementos revealSecrets y un simulacro en la solicitud de TestState API, Step Functions devuelve una excepción de validación.

IAMpermisos para usar la TestState API

El IAM usuario que llama a la TestState API debe tener permiso para realizar la states:TestState acción. Cuando no utilices la función de simulación, el IAM usuario también debe tener permiso para realizar la iam:PassRole acción a la que transferirá la función de ejecución. Step Functions Además, si establece el revealSecrets parámetro entrue, el IAM usuario debe tener permiso para realizar la states:RevealSecrets acción. Sin este permiso, Step Functions produce un error de acceso denegado.

Ten en cuenta que, si especificas un simulacro en la solicitud de TestState API, puedes probar la lógica de tu máquina de estados sin asignar una función de ejecución (consulta más información en la sección sobre integraciones de servicios de Mocking). Cuando no utilices simulaciones, debes proporcionar una función de ejecución que contenga los permisos necesarios para los recursos a los que accede tu estado. Para obtener información acerca de los permisos que podría necesitar su estado, consulte Administración de roles de ejecución.

Prueba de un estado mediante la consola AWS Step Functions

Puede probar un estado en la consola y comprobar la salida del estado o el flujo de procesamiento de datos de entrada y salida. En el caso de una Tarea HTTP, puede probar la solicitud y la respuesta HTTP sin procesar.

Probar un estado usando AWS CLI

Puede probar un estado mediante la TestStateAPI delAWS CLI. La API acepta la definición de un estado y la ejecuta.

Para cada estado, puede especificar la cantidad de detalles que desea ver en los resultados de la prueba. Estos detalles proporcionan información adicional sobre la ejecución del estado, incluido el resultado del procesamiento de datos de entrada y salida y la información de solicitud y respuesta HTTP. Los siguientes ejemplos muestran los diferentes niveles de inspección que puede especificar para la TestState API.

Esta sección contiene los siguientes ejemplos que describen cómo puede utilizar los diferentes niveles de inspección que Step Functions proporciona en AWS CLI:

Ejemplo 1: Uso del InspectionLevel INFO para probar un estado Elección

Para probar un estado mediante el INFO InspectionLevel delAWS CLI, ejecuta el test-state comando como se muestra en el siguiente ejemplo.

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}'

En este ejemplo se utiliza un estado Elección para determinar la ruta de ejecución del estado en función de la entrada numérica que proporcione. De forma predeterminada, Step Functions establece el inspectionLevel en INFO si no se establece un nivel.

Step Functions devuelve la siguiente salida.

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

Ejemplo 2: Uso del InspectionLevel DEBUG para depurar el procesamiento de datos de entrada y salida en un estado Aprobado

Para probar un estado mediante el DEBUG InspectionLevel delAWS CLI, ejecute el test-state comando como se muestra en el siguiente ejemplo.

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

En este ejemplo se usa un estado Estado Pass de un flujo de trabajo para mostrar cómo Step Functions filtra y manipula los datos JSON de entrada mediante los filtros de procesamiento de datos de entrada y salida. En este ejemplo se utilizan los siguientes filtros: InputPath, Parameters, Especificación de la salida de estado mediante ResultPath en Step Functions y Filtrado de la salida de estado mediante OutputPath.

Step Functions devuelve la siguiente salida.

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

Ejemplo 3: Uso del inspectionLevel TRACE y revealSecrets para inspeccionar la solicitud HTTP enviada a una API de HTTPS

Para probar una tarea HTTP mediante el TRACE InspectionLevel junto con el parámetro RevealSecrets delAWS CLI, ejecute el test-state comando como se muestra en el siguiente ejemplo.

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

En este ejemplo se comprueba si la tarea HTTP llama a la API de HTTPS especificada, https://httpbin.org/. También se muestran los datos de solicitud y respuesta HTTP de la llamada a la API.

Step Functionsdevuelve un resultado similar al ejemplo original de la documentación actual.

Ejemplo 4: Uso de la utilidad jq para filtrar e imprimir la respuesta que devuelve la TestState API

La TestState API devuelve datos JSON como cadenas de escape en su respuesta. El siguiente AWS CLI ejemplo amplía el ejemplo 3 y utiliza la jq utilidad para filtrar e imprimir la respuesta HTTP que devuelve la TestState API en un formato legible para las personas. Para obtener información jq y sus instrucciones de instalación, consulte jq on. GitHub

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'

En el siguiente ejemplo se muestra la salida devuelta en un formato legible para las personas.

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

Prueba y depuración del flujo de datos de entrada y de salida

La API TestState es útil para probar y depurar los datos que fluyen a través del flujo de trabajo. En esta sección se proporcionan algunos conceptos clave y se explica cómo utilizarlos TestState para este fin.

Conceptos clave

En Step Functions, el proceso de filtrar y manipular datos JSON a medida que pasan por los estados de su máquina de estado se denomina procesamiento de entrada y salida. Para obtener información sobre cómo funciona, consulte Procesamiento de entradas y salidas en Step Functions.

Todos los tipos de estado del Amazon States Language (ASL) (Tarea, Paralelo, Mapa, Aprobado, Esperar, Elección, Correcto y Error) comparten un conjunto de campos comunes para filtrar y manipular los datos JSON que pasan por ellos. Estos campos son: InputPath, Parameters, ResultSelector, Especificación de la salida de estado mediante ResultPath en Step Functions y Filtrado de la salida de estado mediante OutputPath. La compatibilidad de cada campo varía según el estado. En tiempo de ejecución, Step Functions aplica cada campo en un orden específico. El siguiente diagrama muestra el orden en el que se aplican estos campos a los datos en un estado Tarea:

La siguiente lista describe el orden de aplicación de los campos de procesamiento de entrada y salida que se muestran en el diagrama.

Estos campos de procesamiento de entrada y de salida son opcionales. Si no utilizas ninguno de estos campos en la definición de estado, la tarea consumirá la entrada de estado sin procesar y devolverá el resultado de la tarea como salida de estado.

Se utiliza TestState para inspeccionar el procesamiento de entrada y salida

Cuando llama a la API TestState y establece el parámetro inspectionLevel en DEBUG, la respuesta de la API incluye un objeto llamado inspectionData. Este objeto contiene campos que ayudan a inspeccionar cómo se filtraron o manipularon los datos en el estado cuando se ejecutaron. En el ejemplo siguiente se muestra el objeto inspectionData para un estado Tarea.

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

En este ejemplo, cada campo que contiene el prefijo after muestra los datos después de aplicar un campo concreto. Por ejemplo, afterInputPath muestra el efecto de aplicar el campo InputPath para filtrar la entrada de estado sin procesar. El siguiente diagrama asigna cada campo de definición de ASL a su campo correspondiente en el objeto inspectionData:

Para ver ejemplos del uso de la TestState API para depurar el procesamiento de entrada y salida, consulta lo siguiente:

En lo que respecta específicamente al estado del mapa, cuando inspectionLevel se establece enDEBUG, el inspectionData objeto incluye campos adicionales que le ayudan a inspeccionar cómo el estado del mapa extrae y transforma los elementos. Puede obtener más información sobre estos campos en la sección Descripción de los datos de inspección del estado del mapa.

Comprensión de los datos de inspección del estado del mapa

Cuando pruebas un estado del mapa con el valor inspectionLevel establecido enDEBUG, la respuesta de la TestState API incluye campos adicionales en el inspectionData objeto que muestran cómo el estado del mapa procesa los datos:

Estos campos le permiten validar que las transformaciones de datos y las configuraciones de tolerancia a errores del estado del mapa funcionan correctamente antes del despliegue.

Qué puede probar y comprobar con la TestState API

La TestState API le permite escribir pruebas unitarias completas para sus máquinas de estado. Puedes basarte en varios aspectos de la lógica de tu máquina de estados, incluidos los siguientes:

Gestión de errores: ¿Qué captura o reintento se aplica

Cuando simulas un error, puedes usar la TestState API para ver qué controlador de errores se activa.

En el caso de los bloques Catch, puedes afirmar lo siguiente:

En el caso de los bloques de reintento, puedes afirmar lo siguiente:

Transformaciones de datos: procesamiento de entrada y salida

Con la TestState API, puede validar cómo se transforman los datos de su estado en cada etapa del procesamiento.

Puede hacer valer lo siguiente:

Transformaciones de estado del mapa: ItemSelector, ItemsPath, ItemBatcher, ItemsPointer

En el caso de los estados del mapa, puede usar la TestState API para ver cómo se extraen y transforman los elementos.

Puede hacer valer lo siguiente:

Mapee los umbrales de error del estado: estados de prueba. ExceedToleratedFailureThreshold

Compruebe si un número específico de iteraciones fallidas activa el umbral de error tolerado.

Puede hacer valer lo siguiente:

Propagación de errores en estados de mapa y paralelo

Al probar estados dentro de los estados de mapa o paralelo, los errores se propagan a los controladores de errores del estado principal tal como lo harían en una ejecución real.

Especificar el origen del error con State errorCausedBy

Al simular los errores de los estados de mapa o paralelo, debe especificar qué subestado causó el error mediante el stateConfiguration.errorCausedByState parámetro. Esto es especialmente importante cuando se prueban errores comodín como. States.TaskFailed States.TaskFailedes un error comodín que se aplica a cualquier error de estado de la tarea. Para comprobar cómo gestiona este error tu estado de mapa o paralelo, debes identificar el subestado específico que lo provocó. Consulta el ejemplo que aparece a continuación:

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

En este ejemplo, errorCausedByState indica TestState que el error se produjo por el estado ProcessItem «» del Map/Parallel flujo de trabajo. Los controladores Catch o Retry del Map/Parallel estado principal procesarán el error como lo harían durante la ejecución real. El nextState campo de la respuesta muestra qué controlador de errores detectó el error. Puede hacer valer lo siguiente:

Simulación de las integraciones de servicios

La TestState API permite simular los resultados de las integraciones de servicios, lo que le permite probar la lógica de su máquina de estados sin invocar servicios reales. AWS

¿Cuándo usar la burla

La burla es útil para:

Cuando especificas un simulacro, el roleArn parámetro pasa a ser opcional, lo que te permite centrarte en probar la definición de tu máquina de estados sin tener que lidiar con problemas relacionados con los permisos.

Sintaxis de burla básica

Para simular el resultado de una integración de servicios:

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\"}}"}'

Para simular un error:

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

Modos de validación simulados

La TestState API valida las respuestas simuladas comparándolas con los modelos de API AWS de servicio para garantizar su exactitud. Puede controlar el comportamiento de validación mediante el parámetro: fieldValidationMode

Ejemplo con el modo de validación:

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

Probar los estados de mapa y paralelo

La TestState API permite probar los estados de mapa y paralelo cuando se especifica un simulacro. Esto le permite probar el procesamiento de entrada y salida de estos estados de flujo.

Comprensión de las pruebas de estado del mapa

Cuando pruebas un estado del mapa con la TestState API, estás probando el procesamiento de entrada y salida del estado del mapa sin ejecutar las iteraciones internas. Este enfoque te permite probar:

No estás probando lo que ocurre dentro de ItemProcessor (los estados que procesan cada elemento).

Probando el estado de un mapa

Al probar un estado del mapa, el resultado simulado debe representar el resultado de todo el estado del mapa. El resultado simulado debe ser una matriz JSON válida o un objeto JSON, en función de la configuración del estado del mapa. Consulta el siguiente ejemplo:

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

Probando los estados de los mapas distribuidos

Los estados del mapa distribuido se prueban de forma similar a los estados del mapa en línea. Cuando su mapa utilice una ItemReader para leer desde S3, proporcione los datos directamente en la entrada (como si ya se hubieran leído desde S3). Por ejemplo:

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": "..."}'

Población de contexto automática

Al probar un estado dentro de un estado del mapa (mediante el stateName parámetro) sin proporcionar ningún context parámetro, rellena TestState automáticamente el objeto de contexto con los valores predeterminados. Esto incluye campos de contexto específicos del mapa, como:

Probando estados paralelos

Al probar un estado paralelo, el resultado simulado debe ser una matriz JSON con un elemento para cada rama, en el mismo orden en que aparecen las ramas en la definición.

Actividad de prueba, .sync y. waitForTaskEstados simbólicos

La TestState API permite probar los estados de actividad, los patrones de integración del servicio.sync y. waitForTaskPatrones de símbolos cuando se especifica un simulacro. Sin una simulación, la invocación de estos estados a través de la TestState API devolverá una excepción de validación.

Repasando en iteraciones las definiciones de las máquinas de estados

Puede proporcionar una definición completa de la máquina de estados a la TestState API y especificar qué estado desea probar mediante el stateName parámetro. Esto le permite probar ese estado específico en el contexto de su máquina de estados completa. También puede encadenar pruebas utilizando la salida y nextState de una prueba como entrada a la siguiente. Esto le permite probar rutas de ejecución parciales o completas dentro de su máquina de estados.

Uso del campo de contexto en la TestState API

El context parámetro permite proporcionar valores para el objeto Context que normalmente se rellenarían durante la ejecución. Esto resulta útil para probar estados que hacen referencia a valores de contexto como el identificador de ejecución, el nombre del estado o la hora introducida. En el siguiente ejemplo, se muestra cómo puedes usar el objeto Context en tu llamada a la TestState API:

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\"}"}'

Probar, reintentos y manejo de errores

La TestState API te permite simular escenarios de reintentos y probar la lógica de gestión de errores especificando los reintentos y simulando los errores.

Simulación de reintentos

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

La respuesta incluye detalles del error en los datos de inspección:

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

Esta respuesta indica:

Prueba de manipuladores de capturas

Cuando un error es simulado y coincide con un controlador de Catch, el nextState campo de la respuesta de la TestState API indica en qué estado se gestionará el error. En el siguiente ejemplo:

Para la solicitud de TestState API que se indica a continuación,

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

La respuesta de la API esperada debería ser:

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

Esta respuesta indica que:

También puedes comprobar qué ocurre cuando se agotan todos los reintentos aumentando RetryCount los valores del objeto de contexto.