Corridas y Depuración

Cuando una automatización se porta mal, la respuesta rara vez está en la automatización. Está en la corrida. Una corrida registra qué pasó realmente, paso por paso, con los valores que de verdad estaban ahí en lugar de los que esperabas.

Qué registra una corrida

Cada ejecución guarda su origen de disparo, su estado, y una entrada por paso. Una entrada de paso lleva:

El campo de entrada es el que resuelve la mayoría de los problemas. Las plantillas ya están resueltas cuando el nodo corre, así que la entrada muestra el valor que llegó — no la plantilla que escribiste. Un flujo que se ve correcto y se comporta mal casi siempre es una plantilla que resolvió a algo distinto de lo que suponías, y acá es donde se ve.

Estados

Una corrida, y cada uno de sus pasos, puede estar en:

Salteada no es falla. Una rama que no corrió deja sus nodos salteados, y eso normalmente es correcto — solo es un problema cuando esperabas que esa fuera la rama tomada. Leer un camino false lleno de nodos salteados como "roto" manda a la gente a depurar la mitad equivocada del flujo.

Origen del disparo

Cada corrida dice cómo arrancó: manual, evento, webhook, agendado, u otra automatización llamándola.

Eso responde una confusión concreta y frecuente — ¿por qué corrió esto a las 3 de la mañana si nadie tocó nada? — y distingue un flujo que iniciaste probando de uno que inició el sistema por su cuenta.

Dónde salen mal las cosas de verdad

Ordenado por frecuencia:

Una plantilla apuntó a nada. Mirá la entrada del paso. Si muestra una cadena literal {{context.steps...}}, un nodo anterior no corrió, o su clave es distinta de la que escribiste.

Una rama salteada alimentó a un nodo posterior. La plantilla de un nodo bypaseado llega como texto, que es truthy, así que los fallbacks con || no te salvan. Arreglá la rama, no el valor.

Una comparación contra un nombre visible. Las columnas de Estado vuelven como ids de opción. Una condición que busca "Aprobado" no coincide nunca.

No había nada configurado para enviar. El correo que nunca llega suele ser un workspace sin proveedor de mailing configurado, no un nodo roto.

Falló la API de un tercero. Mirá el error del paso antes de suponer que la culpa es del flujo. Para eso está Try/Catch.

Hábitos que hacen legibles las corridas

Nombrá los pasos por lo que hacen. Un paso llamado queryCustomers se busca en la lista de corridas y se lee en una plantilla. Los nombres por defecto no.

Dejá notas en el lienzo. El nodo Note no cuesta nada y explica una decisión que después no va a ser obvia.

Envolvé las llamadas externas en Try/Catch, y escribí el error en algún lado. Un error atrapado que se desvanece es apenas mejor que un crash — ponelo en una fila o en un mensaje para que una falla se descubra sin abrir el historial de corridas.

Probá con un trigger manual. Armá el flujo con trigger manual, corrilo hasta que esté bien, y después cambiá al real. Depurar un agendado esperando a las 3 de la mañana es una mala forma de gastar una semana.

Los secretos quedan fuera de las corridas

Un valor leído con el nodo Vault nunca aparece en la entrada, la salida ni los logs de un paso. Es deliberado, y significa que una corrida se puede compartir con un colega sin riesgo.

El corolario: todo lo que pegues en un campo de configuración común sí aparece. Esa es la razón práctica más fuerte para usar el Vault en vez de un campo de configuración — no que alguien te lo robe, sino que va a quedar en el historial de corridas, en las exportaciones, y en la captura de pantalla que le mandes a quien te esté ayudando.

Siguiente

• Lógica del lado del servidor — Try/Catch y manejo de errores en profundidad

• Nodos de lógica — ramificación, y por qué importa el camino False

• Panorama de automatizaciones — contexto y plantillas, desde el principio