Saltar al contenido principal

​
Manejo de errores

Usa la documentación de manejo de errores de flujos de trabajo cuando una solicitud de flujo de trabajo falle, un paso se comporte de forma inesperada o la entrega por callback no se complete como esperabas. El objetivo es separar los problemas de validación de la solicitud de los fallos en tiempo de ejecución del flujo de trabajo para que sepas dónde buscar a continuación.

​
Resumen

Los fallos del flujo de trabajo ocurren en dos capas distintas. La primera capa es la validación de la solicitud en la ruta pública de invocación. La segunda capa es la ejecución del flujo de trabajo después de que la ejecución comienza. Para los fallos de ejecución, la superficie de depuración más útil es Registros, donde puedes inspeccionar la hoja de detalle de la ejecución, la cascada de trazas, la salida y los intentos de entrega por callback.

​
¿Cómo manejo los errores de solicitud de invocación de un flujo de trabajo?

Comienza con el cuerpo de la respuesta de POST /v1/workflow/invoke. La ruta pública actual devuelve explícitamente errores de validación cuando faltan campos requeridos de invocación o son inválidos. Ejemplos: 
{
  "error": "Missing required field: deployment or variant"
}

{
  "error": "callback_url is required when async is enabled"
}

{
  "error": "callback_url must be a valid URL"
}
Corrige estos problemas a nivel de solicitud antes de inspeccionar el flujo de trabajo en sí.

​
¿Cómo controlo qué sucede cuando un paso del flujo de trabajo falla?

Abre el flujo de trabajo en el editor. Haz clic en un paso para abrir Step settings. Para los tipos de paso que exponen el ajuste, usa When the step fails para elegir si el flujo de trabajo debe detenerse o continuar después de que ese paso falle. Usa Terminate Workflow cuando el flujo de trabajo deba detenerse inmediatamente ante ese fallo. Usa Continue cuando un paso fallido no deba bloquear el resto del flujo de trabajo. Este ajuste afecta el comportamiento en tiempo de ejecución, así que prueba el flujo de trabajo nuevamente después de cambiarlo.

​
¿Cómo depuro una ejecución fallida de un flujo de trabajo?

Abre Registros. Encuentra la ejecución fallida en la tabla, luego ábrela. Usa la cascada de trazas para identificar dónde ocurrió el fallo. Revisa los detalles del span seleccionado, los detalles de la solicitud, las entradas de inicio, la metadata y las secciones de salida mientras avanzas por la ejecución. Si el flujo de trabajo usó entrega por callback, también inspecciona Webhook Logs para ver el conteo de reintentos, el código de respuesta, el payload y el cuerpo de la respuesta. Esta es la mejor manera de separar un fallo de paso de un problema de entrega.

​
¿Qué estados de fallo en tiempo de ejecución debo esperar?

La ruta pública actual del flujo de trabajo puede mostrar estados de fallo terminal como:
  • failed
  • cancelled
También puede devolver un fallo por timeout si la ruta de respuesta directa espera demasiado a que el flujo de trabajo termine. Por ejemplo: 
{
  "request_id": "req_019d52846ea37682b03522fd0695cc43",
  "run_status": "failed",
  "error": "Workflow timed out"
}
O: 
{
  "request_id": "req_019d52846ea37682b03522fd0695cc43",
  "run_status": "cancelled",
  "error": "Workflow run was cancelled"
}
Trata estos como fallos de tiempo de ejecución, no como problemas de formato de la solicitud.

​
Notas sobre el manejo de errores

Si la solicitud de invocación tiene éxito pero el flujo de trabajo falla más tarde, ve a los registros del flujo de trabajo en lugar de cambiar primero el payload de la solicitud. Si la solicitud de invocación misma devuelve un objeto error inmediatamente, corrige esa solicitud antes de invertir tiempo depurando el editor del flujo de trabajo. Consulta también: Ejecutar con API, Entrega por callback y disparadores de webhook y Registros