Qué necesita
- Un escenario de Make.com con al menos un módulo que pueda fallar, como HTTP – Make a request o Google Sheets
- Acceso a los ajustes del escenario y a la pestaña History
- Un sitio al que enviar alertas, como Gmail o Slack
Paso a paso: añadir una ruta de error handler y elegir un handler
1. Sepa qué ocurre sin handler
Sin handler, lo que ocurre depende del ajuste Store incomplete executions. Si está desactivado, Make aplica Rollback: la ejecución se detiene con estado de error y, tras 3 errores seguidos por defecto (ajuste Number of consecutive errors), Make desactiva el escenario. Un escenario que empieza con un disparador instantáneo se desactiva tras el primer error. Si el ajuste está activado, Make guarda la ejecución fallida como incomplete execution y la ejecución termina con una advertencia. Los módulos que admiten transacciones, marcados con la etiqueta ACID, como los de Data store o MySQL, deshacen sus cambios. Módulos como Gmail, Google Sheets o HTTP no lo hacen, así que lo que ya hicieron queda hecho.
2. Añada una ruta de error handler
Haga clic derecho en el módulo que puede fallar y elija Add error handler. Aparece una ruta que se ramifica desde el módulo. Todo lo que coloque en ella se ejecuta solo cuando ese módulo da error. La ruta no tiene que terminar en un error handler: si nada falla en ella, Make omite el error, de modo que una ruta con solo un módulo de notificación se comporta como Skip. Puede añadir un filtro en el primer enlace de la ruta para que errores distintos vayan a handlers distintos.
3. Elija el error handler al final de la ruta
Esto es lo que hace cada uno, en lenguaje llano.
Skip (antes Ignore) retira el bundle fallido del flujo y continúa con el siguiente. La ejecución termina con estado correcto y no se guarda nada. Úselo cuando perder un elemento sea aceptable, por ejemplo una fila defectuosa en un lote que registra en otro sitio.
Resume sustituye la salida del módulo fallido por valores que usted indica, y el escenario continúa después de ese módulo como si hubiera tenido éxito. Úselo cuando exista un valor por defecto razonable, como "unknown" para una búsqueda que no devolvió nada. Cuidado: esos valores sustitutos fluyen a todo lo que viene después.
Retry (antes Break) retira el bundle fallido del flujo y lo guarda, con los pasos restantes, como incomplete execution, para reintentarlo más tarde, automáticamente o a mano. Con Automatically complete execution activado, fija el número de intentos y el intervalo entre ellos. Los demás bundles continúan y la ejecución termina con una advertencia. Úselo cuando los datos importan y el error probablemente sea temporal, como un límite de peticiones o una caída. Retry requiere que Store incomplete executions esté activado en los ajustes del escenario, y Make marca el handler hasta que lo active.
Rollback detiene la ejecución, la marca como error y revierte los cambios en los módulos que admiten transacciones. Cuenta para el límite de errores consecutivos. Úselo solo cuando escriba en algo transaccional, como una base de datos donde una actualización a medias sería peor que ninguna.
Commit detiene la ejecución y confirma los cambios hechos hasta ese momento por los módulos transaccionales. Los módulos restantes no se procesan y la ejecución termina con una advertencia. Es la contrapartida de Rollback y rara vez hace falta en escenarios construidos con Google Sheets y Gmail.
4. Construya un ejemplo práctico con HTTP – Make a request
Supongamos que el escenario lee filas de Google Sheets y envía cada una a una API.
- En el módulo HTTP, ponga Evaluate all states as errors (except for 2xx and 3xx) en Yes. Así se llama la opción en la documentación de Make para los módulos HTTP (legacy); la app HTTP más reciente puede llamarla de otra forma. De lo contrario, una respuesta 429 o 500 puede pasar por éxito. Con esta opción activada, el cuerpo de la respuesta de una llamada fallida no suele estar disponible en la ruta de error.
- Añada una ruta de error handler al módulo HTTP.
- Ponga un filtro en el primer enlace de la ruta para límites de peticiones y errores de servidor, por ejemplo código de estado 429 o 500 en adelante. Los nombres exactos de los campos los verá en la salida de error de un Run once fallido.
- En esa ruta, añada el error handler Retry con 3 intentos y un intervalo de 10 minutos. El bundle se guarda y se reintenta.
- Añada una segunda ruta para errores del cliente (un 400 o 404 causado por una fila defectuosa). Envíe un correo o un mensaje de Slack con los datos de la fila y el texto del error, que mapea desde la salida de error del módulo fallido en el panel de mapeo, y termine con Skip, para que una fila mal formada no retenga a las demás.
5. Añada un ejemplo con Google Sheets para el registro
En la ruta de Skip, antes del error handler, añada Google Sheets – Add a Row a una hoja llamada "Errors" con la hora {{now}}, el nombre del escenario, el registro afectado y el mensaje de error. Una hoja de registro convierte los fallos invisibles en algo legible a la mañana siguiente.
6. Entienda cómo se relaciona con las incomplete executions
Cuando Retry guarda un bundle, aparece en la pestaña Incomplete executions del escenario. Desde ahí puede abrirlo, ver el error, corregir la causa y reintentarlo, o eliminarlo. Con reintentos automáticos configurados, Make lo vuelve a intentar por sí mismo. Si Process data in order está activado, Make aplaza las ejecuciones nuevas hasta que se resuelvan las incomplete executions, así que revise la pestaña con regularidad. Además, Make no guarda una incomplete execution cuando el error se produce en el primer módulo, salvo que ese módulo tenga un handler Retry. El almacenamiento de incomplete executions no es ilimitado; consulte los límites vigentes de su plan.
7. Pruebe el handler a propósito
Rompa algo deliberadamente: una clave de API errónea o una URL no válida, ejecute una vez y observe qué ruta se ejecuta. Un handler que nunca ha activado es un handler cuyo funcionamiento desconoce.
Errores frecuentes y soluciones
Retry (Break) no sirve de nada. Store incomplete executions está desactivado en los ajustes del escenario, así que el bundle no tiene adónde ir. Actívelo y pruebe de nuevo.
Los fallos desaparecen sin dejar rastro. Se usó Skip (Ignore) sin registro ni alerta. Añada siempre una fila de registro o una notificación antes del error handler.
Aparecen datos incorrectos más adelante tras un error. Resume aportó un valor de relleno y los módulos posteriores lo trataron como real. Use Resume solo con valores seguros, o deje que el valor vacío llegue a un filtro que lo detenga.
Rollback "no deshizo" el correo ni la fila de la hoja. Rollback solo revierte módulos transaccionales. Gmail, Google Sheets y las llamadas HTTP simples no están cubiertos. Si necesita evitar trabajo parcial, ordene los módulos de modo que el paso irreversible quede al final.
El handler nunca se ejecuta con HTTP 4xx o 5xx. El módulo HTTP está tratando esas respuestas como correctas. Active la opción que evalúa como error todos los estados que no son éxito.
Los reintentos crean duplicados. Retry vuelve a ejecutar la ejecución guardada, y si el primer intento tuvo éxito a medias en el otro extremo, aparece una segunda copia. Donde la API lo admita, envíe una clave de idempotencia, o compruebe primero si el registro ya existe.