Errores y reintentos

Cuando un paso informa de un error, como un HTTP 404, un permiso denegado, un valor del tipo equivocado, un valor ausente o un límite que el paso supera, el run termina como fallido al instante. No hay reintento del paso ni opción en el paso para continuar. La única forma de seguir tras un fallo es poner el paso dentro de un «Intentar» ; consulta Seguir adelante tras un fallo.

• Un paso fallido no se cobra.
• El motor no reintenta ante un 500 de tu servidor ni ante un timeout. Corrige la causa y pulsa Reintentar en la ejecución.
• El error se guarda en el paso, así que el visor de ejecuciones muestra exactamente qué paso se detuvo y por qué.

El «Intentar» ("Si un paso falla, continúa") no tiene campos y tiene un cuerpo, como un bucle. Ejecuta los pasos de dentro. Si uno de ellos falla, los pasos que le siguen dentro del cuerpo se omiten y el run continúa con el paso que sigue al Intentar, en lugar de terminar como fallido.

Un Intentar publica solo su resultado, como «Resultado del intento». Las variables que crearon los pasos de dentro no salen: tras un fallo, algunas pueden no existir.

• Captura los fallos de los pasos: una respuesta HTTP que no es 2xx, el error que devuelve una acción, un valor no válido y un crédito agotado. Un bucle que supera sus vueltas también es un fallo de paso.
• No captura lo que no es un fallo de paso. Una avería del motor (se reintenta como se describe en la sección siguiente), un error fatal (listado después) y un Salto lo atraviesan, y también una espera: una espera dentro de un Intentar aparca el run como siempre.
• Pasos Intentar anidados: el más interno captura el fallo.
• El propio paso Intentar no gasta crédito ni ocupa posición en el run. Los pasos de dentro cuentan como siempre; un paso que falló no se cobra.
• En «Desarrollo a medida», el mensaje de un fallo dentro de un Intentar es el genérico.

1. 1

   Envuelve los pasos que pueden fallar

   Añade un «Intentar» y suelta dentro los pasos que pueden fallar, como una petición HTTP a un sistema que a veces está caído.

2. 2

   Comprueba el resultado

   Después del Intentar, añade una «Condición» en «Resultado del intento» «Ha fallado» (es igual a verdadero).

3. 3

   Indica qué hacer

   En la rama del fallo, avisa a alguien, crea una tarea o toma otro camino, usando el mensaje de error en el texto. En la otra rama, sigue adelante.

• Si no compruebas el resultado, el fallo es silencioso: el run continúa y nadie se entera. Pon la comprobación después del Intentar.
• Un run en el que se capturó cada fallo termina como completado, y no se envía ningún aviso de fallo.
• En el visor de runs, el paso que falló dentro del Intentar aparece marcado como error capturado (rojo atenuado, discontinuo). El propio panel del Intentar muestra el mensaje, o "Sin errores".
• Cuando un run se reanuda tras una espera, un fallo capturado se repite en el mismo punto a partir del registro: el paso que falló no se vuelve a ejecutar.

Si el propio motor lanza un error (una excepción inesperada, un problema de base de datos), la ejecución no se marca como fallida de inmediato. Espera y lo vuelve a intentar, tres intentos en total:

• Las esperas son mínimos: la ejecución la despierta el siguiente tick de un minuto, así que cada una puede durar hasta aproximadamente un minuto más.
• Solo se repite el trabajo fallido. Los pasos completados se reproducen desde el registro y no cuestan nada.
• Un paso de espera no es un intento fallido y no gasta uno. Un workflow con tres esperas no se queda sin intentos.
• Un worker que muere a mitad de ejecución se detecta cuando caduca su lease de cinco minutos. El relevo cuenta como un intento. Si la ejecución ya estaba en el tercero, termina como fallida con "the run died 3 times without completing; it is not retried again".

Algunos errores fallarían igual cada vez y solo repetirían de paso los efectos de un paso, así que terminan la ejecución como fallida de inmediato:

El límite del bucle es un fallo de paso, no un error del motor: termina el run como fallido (salvo que el bucle esté dentro de un Intentar) con "el bucle superó las N vueltas permitidas", y Reintentar lo reproduce.

• En la tarjeta de la ejecución, una ejecución fallida muestra el mensaje de error en rojo. El código de error no aparece ahí. Si no hay mensaje, la tarjeta dice "Algo ha fallado durante la ejecución".
• Haz clic en el paso fallido. Su panel se abre en el «Error» pestaña con, cuando existen: «Estado HTTP» (para HTTP), «Respuesta» (el cuerpo), «Campos» (qué campo y por qué), «Detalles» y «Código».
• Un paso que ha fallado porque un impuesto no está asignado en un paquete de contabilidad muestra un botón, «Asignar el impuesto en {{provider}}», que abre el mapa. Después de guardarlo, la app ofrece reintentar las ejecuciones que quedaron bloqueadas.
• Los mensajes que escribe el motor están en español sea cual sea el idioma de la app. Los mensajes de esta documentación son traducciones.

Pulsar «Reintentar» en una ejecución fallida. Usa la misma ejecución, reinicia sus intentos a cero, elimina solo los registros fallidos y empieza de nuevo: los pasos completados se reproducen y el paso fallido se ejecuta en vivo. Ejecuta la versión con la que empezó la ejecución, así que editar el workflow no la cambia. No comprueba tu crédito antes de ponerla en cola; si no hay, la ejecución se pausa en el paso que lo necesita. No hay forma de aportar una entrada distinta.

Un run no repite los pasos ya terminados. Pero si un worker muere después de que ocurriera el efecto de un paso y antes de que Filmo registrara que el paso terminó (una ventana muy breve), el paso se ejecuta de nuevo. Filmo reduce esa ventana en tres capas y no afirma cerrarla:

En los ajustes del workflow, «Avisar si falla» ofrece «Notificación interna y email» (el valor por defecto), «Solo notificación interna», «Solo email» y «No notificar».

• Las personas avisadas son el creador del workflow, si todavía tiene acceso a la empresa; si no, todos los administradores (propietarios y administradores; el rol de soporte de Filmo nunca recibe el aviso). Nunca la persona que pulsó el botón.
• Se envía un aviso interno en cada fallo, con el nombre del workflow y el principio del error (cortado a 200 caracteres), enlazando a la ejecución.
• Se envía como máximo un email por hora y por workflow, sea cual sea el fallo que llegue primero. El email nombra el workflow y enlaza a la ejecución; no incluye el motivo. La hora se gasta aunque el email falle al enviarse.
• Una pausa, una cancelación y un intento fallido que se va a reintentar no envían nada. El aviso se envía cuando el run ha terminado como fallido. Un run cuyos fallos capturó todos un Intentar termina como completado y no envía ninguno.
• Como el email se limita a uno por hora, una ráfaga de fallos produce un email y muchos avisos internos.