Una ejecución hecha por otra persona no aparece ni funciona, pero funciona cuando la ejecuto yo

[Rafael_Van_Meerbeek]

El 29 de abril, mi madre ejecutó el workflow desde la página web, pero esa ejecución no aparece en n8n y tampoco funcionó correctamente. Sin embargo, cuando ejecuto el mismo workflow desde la página web yo mismo, funciona sin ningún problema.
Me gustaría entender por qué puede suceder esto:
por qué una ejecución puede no guardarse o mostrarse,
por qué funciona para mí pero no para otra persona,
y si podría estar relacionado con permisos, autenticación, sesión o la forma en que se ejecuta el workflow.
Si alguien ha experimentado algo similar, realmente apreciaría cualquier ayuda.

[kjooleng]

Este es un escenario común en automatización donde “funciona en mi máquina” se convierte en una realidad de solución de problemas. Dado que la ejecución no aparece en el historial de n8n en absoluto, esto sugiere que el problema está ocurriendo antes de que la lógica del flujo de trabajo se procese completamente o durante la transferencia entre la página web y el webhook de n8n.

Aquí hay un desglose de las posibles razones, categorizadas por dónde probablemente ocurrió el fallo.

1. Por qué una ejecución podría no guardarse o mostrarse

Si una ejecución no aparece en la pestaña “Executions” de n8n, generalmente significa una de estas tres cosas:

o La solicitud nunca llegó a n8n: El disparador (nodo Webhook) nunca recibió exitosamente la solicitud HTTP. Si la solicitud fue bloqueada por un firewall, un error CORS o un problema de red, n8n nunca la “vio”, por lo que no pudo crear un registro de ejecución.

o Error durante la fase de “Trigger”: Si el error ocurre dentro del nodo Webhook mismo (por ejemplo, una discrepancia en los encabezados esperados o una falla de autenticación a nivel de servidor), n8n podría rechazar la solicitud con un error 401, 403 o 404 antes de que el motor del flujo de trabajo incluso inicie una “ejecución” formal.

o Configuración de n8n: En n8n, existe una opción para “Save Successful Executions” (Guardar ejecuciones exitosas). Si el flujo de trabajo realmente tuvo éxito pero tenía un error que lo hizo parecer que falló, y tienes “Save Successful Executions” desactivado, no lo verás. Sin embargo, dado que mencionaste que “no funcionó correctamente”, es más probable que sea un fallo.

2. Por qué funciona para ti pero no para otra persona

Esto apunta a diferencias en el lado del cliente (el navegador/dispositivo) o el entorno de red.

o Problemas de CORS (Cross-Origin Resource Sharing): Este es el culpable más probable. Si la página web está alojada en dominio-a.com y tu n8n está en dominio-b.com, el navegador realiza una verificación de “preflight”. Si tu navegador tiene un permiso en caché o una configuración de seguridad diferente, podría pasar, mientras que su navegador (quizás con configuraciones de privacidad más estrictas o diferentes extensiones) bloquea la solicitud.

o Diferencias en datos/carga: Cuando tu madre dispara el flujo de trabajo, ¿ingresa exactamente los mismos datos que tú? Si la página web envía un formulario y ella ingresa un carácter especial, deja un campo en blanco o introduce un valor que viola un esquema (por ejemplo, una cadena de texto donde se espera un número), el flujo de trabajo podría fallar en el primer nodo.

o Autenticación y sesiones:

o Cookies/Tokens: Si la página web depende de una cookie de sesión o un token Bearer para autorizar el disparador, y su sesión ha expirado o no inició sesión correctamente, la solicitud será rechazada.

o Whitelist de IP: Si tu instancia de n8n está detrás de un firewall que solo permite ciertas direcciones IP, tu IP podría estar permitida, mientras que la suya (en una red diferente o VPN) está bloqueada.

o Extensiones del navegador/Bloqueadores de anuncios: Muchos bloqueadores de anuncios o extensiones de privacidad (como uBlock Origin o los shields del navegador Brave) interceptan solicitudes “inusuales” salientes. Si la URL del webhook parece un script de rastreo para su navegador, será eliminada antes de dejar su computadora.

3. Lista de verificación de resumen para la solución de problemas

Para encontrar la causa exacta, te recomiendo investigar en este orden:

[Exnav29]

Muy detallado, @Rafael_Van_Meerbeek estoy 95% seguro de que si sigues las recomendaciones de @kjooleng resolverás tu problema. En cuanto al otro 5%, podrías intentar eliminar el nodo de activación y comenzar con uno nuevo.

[Rafael_Van_Meerbeek]

hey muchas gracias, esto me ha ayudado mucho, ahora vuelve a funcionar pero he notado que cuando tengo el flujo de trabajo abierto cambia de conexión perdida a normal cada segundo, como en las capturas de pantalla y en las ejecuciones de prod. ¿Podrías explicar por qué sucede esto?

[dima_automation]

la pérdida de conexión parpadeante mientras el flujo de trabajo está abierto suele ser un problema de estabilidad de websocket. las causas comunes en docker autohospedado: nginx no configurado para actualizaciones de websocket, o un tiempo de espera de proxy más corto que el intervalo de keepalive.
verifica que tu configuración de nginx tenga proxy_http_version 1.1 y los encabezados Upgrade y Connection configurados correctamente. si tienes un equilibrador de carga o proxy inverso con un tiempo de espera corto, esa es casi siempre la causa. la conexión se cae, se reconecta, se cae de nuevo cada pocos segundos.

[kjooleng]

@Rafael_Van_Meerbeek

¿Podrías explicar por qué ocurre esto?

El mensaje “Conexión perdida” parpadeando es un síntoma clásico de un canal de comunicación en tiempo real inestable entre tu navegador y el servidor de n8n.

n8n no simplemente “actualiza” la página para mostrarte cambios; utiliza una tecnología llamada WebSockets (o a veces Server-Sent Events) para mantener un “canal en vivo”. Esto permite que el servidor envíe actualizaciones a tu pantalla inmediatamente (como cuando un nodo termina de ejecutarse o comienza una nueva ejecución).

Cuando lo ves parpadear cada segundo, significa que el “latido del corazón” (la señal que dice “¡Sigo aquí!”) está siendo interrumpido.

Aquí están las razones más probables por las que esto está sucediendo:

1. Configuración de Reverse Proxy (La #1 Causa)

Si estás ejecutando n8n detrás de un reverse proxy como Nginx, Traefik, Apache o Cloudflare, el proxy es probablemente el culpable.

• Soporte de WebSocket: Los WebSockets requieren encabezados específicos (Upgrade y Connection) para funcionar. Si tu proxy no está configurado para “permitir” estos encabezados, matará la conexión tan pronto como intente establecerse.

• Configuración de Timeout: Los proxies a menudo tienen un “read timeout” o “idle timeout”. Si el proxy cree que la conexión ha estado en silencio demasiado tiempo (incluso si solo está esperando una tarea), la cerrará. El navegador entonces intenta reconectarse inmediatamente, creando ese ciclo de “parpadeo”.

• Cloudflare/WAF: Si usas Cloudflare, su configuración de seguridad o “Rocket Loader” a veces pueden interferir con las conexiones WebSocket persistentes.

2. Agotamiento de Recursos del Servidor

La captura de pantalla “Prod. executions” mostrando una caída de -98.46% es una pista significativa. Esto sugiere que el sistema está experimentando una inestabilidad masiva.

• Picos de CPU/RAM: Si el servidor que ejecuta n8n está alcanzando el 100% de CPU o se está quedando sin RAM, el proceso de n8n se vuelve “no responsivo” durante milisegundos. Durante esos milisegundos, falla al responder a la señal de “latido del corazón” del navegador, causando el error “Conexión perdida”.

• Cuellos de Botella de Base de Datos: Si tu base de datos (PostgreSQL/SQLite) está teniendo dificultades para escribir datos de ejecución, todo el proceso de n8n puede congelarse momentáneamente, rompiendo la conexión en vivo.

3. Inestabilidad de Red

• Pérdida de Paquetes: Si tu conexión a internet local o la ruta de red a tu servidor está perdiendo incluso un pequeño porcentaje de paquetes de datos, el WebSocket —que es muy sensible a interrupciones— se desconectará y reconectará constantemente.

• VPN/Firewall: Si estás en una VPN corporativa, podría estar inspeccionando agresivamente el tráfico y terminando conexiones de larga duración que percibe como “sospechosas” o “inactivas”.

4. Lo que significa la caída “Prod. executions”

La caída de porcentaje masiva en tu captura de pantalla generalmente significa una de dos cosas:

1. Brecha de Datos: Porque la conexión es inestable, el panel de control falla al obtener el historial reciente, haciéndolo parecer como si las ejecuciones se hubieran desplomado.

2. Falla del Sistema: El problema subyacente causando el parpadeo de la conexión (como alto uso de CPU o un servicio que se bloquea) en realidad está impidiendo que los flujos de trabajo se ejecuten correctamente, conduciendo a una caída real en ejecuciones de producción exitosas.

Pasos Recomendados para Solucionar Problemas:

1. Comprueba la Salud del Servidor: Ejecuta top o htop (en Linux) para ver si CPU o Memoria están aumentando cuando ocurre el parpadeo.

2. Comprueba los Registros del Proxy: Si usas Nginx, comprueba /var/log/nginx/error.log. Busca “upstream timed out” o “connection reset by peer”.

3. Prueba la Conexión “Directa”: Si es posible, intenta acceder a n8n a través de su dirección IP y puerto (por ejemplo, http://your-ip:5678) evitando el dominio/proxy. Si el parpadeo se detiene, el problema es definitivamente tu configuración de proxy.

4. Inspecciona la Consola del Navegador: Presiona F12 en tu navegador, ve a la pestaña Consola, y busca errores como WebSocket connection to 'wss://...' failed. Esto confirmará si es un error de conexión.