Bug: Los nodos aparecen como "Fijados" en ejecuciones de workflow sin pruebas

Describe the problem/error/question

Por alguna razón, los nodos que están fijados en mi flujo de trabajo se muestran como “Fijado” en la pestaña de ejecución aunque la ejecución no sea una ejecución de prueba.

He intentado desfijar el nodo, sin embargo sigue mostrándose como “Fijado” en las ejecuciones después de que el nodo haya sido desfijado y vuelto a publicar.

What is the error message (if any)?

No hay mensaje de error.

Information on your n8n setup

  • n8n version: 2.21.8
  • Database (default: SQLite): default Cloud
  • n8n EXECUTIONS_PROCESS setting (default: own, main): default
  • Running n8n via (Docker, npm, n8n cloud, desktop app): n8n cloud
  • Operating system: Windows 11, Helium Chromium browser

Hola @Evan711

Parece que tu interfaz de n8n está mostrando una insignia de «Fijado» por error, lo cual es probablemente un error visual en lugar de un problema con los datos reales de tu flujo de trabajo. Aunque hayas desfijado el nodo, es posible que tu navegador o el servicio en la nube de n8n esté «recordando» la configuración anterior debido a un problema de caché. Esto significa que tu flujo de trabajo probablemente está funcionando normalmente con datos reales, pero la pantalla está mostrando incorrectamente el estado de fijado.

Para solucionar esto, primero debes intentar una «actualización forzada» de tu navegador (Ctrl+F5 o Cmd+Shift+R) para limpiar cualquier información atascada. Si eso no funciona, intenta eliminar el nodo y agregar uno nuevo para restablecer su configuración. Puedes verificar si el problema es solo un error visual descargando tu flujo de trabajo como un archivo JSON; si la palabra «pinData» no aparece en ese archivo, entonces tu flujo de trabajo está perfectamente bien y la insignia de «Fijado» es simplemente un error de visualización que deberías reportar al soporte de n8n help@n8n.io

@Evan711 el icono naranja/amarillo en «When Executed by Another Workflow» podría no ser realmente el indicador de datos anclados — también puede ser la señal visual de n8n indicando que el trigger recibió datos de entrada desde el nodo Execute Workflow de un flujo de trabajo padre. ¿los datos anclados reales siguen apareciendo en el panel de entrada/salida de ese nodo cuando haces clic en él, o solo el icono que se ve anclado?

¡Bienvenido @Evan711 a nuestra comunidad! Soy Jay y soy un creador verificado de n8n.

La intuición de Achamm es correcta - el indicador naranja en el nodo disparador “When Executed by Another Workflow” no significa que pinData esté activo. Es la señal visual de n8n que indica que el disparador recibió datos en vivo del nodo Execute Workflow de un flujo de trabajo padre. Este es el comportamiento esperado para flujos de trabajo secundarios.

Para confirmar que no hay pinData real en el nodo, descarga tu flujo de trabajo como JSON y busca la cadena pinData dentro del archivo. Si está ausente, los datos en ese nodo son 100% datos en vivo del padre, no fijados - la insignia es simplemente la forma de la interfaz de mostrar que el nodo recibió entrada externamente en lugar de dispararse por su propio disparador. Puedes ignorarlo sin problema.

Estoy publicando aquí en lugar de abrir un nuevo issue porque estoy bastante seguro de que estoy viendo lo mismo. Tuve un problema esta mañana donde un webhook se disparó tres veces. Cuando miro el nodo webhook en n8n, no solo muestra que los datos están fijados, sino que muestra los datos fijados en la salida en lugar de los datos reales que dispararon el webhook. Definitivamente no está mostrando los datos reales de ejecución.

He creado dos vídeos que muestran esto en acción. El primero es una demostración del problema. El segundo es una demostración de por qué esto es un problema, donde Baserow afirma que disparó el webhook una vez pero n8n afirma que fue tres veces. Este problema con los datos fijados mostrándose en la pestaña Executions hace que sea imposible solucionar problemas cuando los datos del webhook siguen fijados en la pestaña Editor.

Abrí un issue en GitHub para esto, ya que estoy bastante seguro de que esta comunidad es solo soporte de “teatro AI-slop” copiado y pegado de ciegos guiando a ciegos. Solo quería que el OP sepa que no está loco y que “recarga duro tu navegador porque es un glitch visual” o “está bien porque probablemente no sea real” pueden ser descartados como respuesta.

¡Gracias Adrian! Tu video demuestra exactamente el problema que estoy teniendo. Me alegra saber que no estoy loco. Definitivamente es un problema de n8n y no de mi navegador.

Estoy enfrentando exactamente el mismo problema y está causando errores críticos en nuestros flujos de trabajo.

Justo como mencionaste, los nodos fijados ahora se están filtrando en ejecuciones de producción. Esto anula completamente el propósito de la función, ya que dependemos de datos fijados únicamente para probar flujos en el editor sin afectar el flujo de trabajo publicado y activo. Ahora, todos nuestros webhooks/disparadores activos están ignorando los datos entrantes reales y están utilizando los datos simulados fijados en su lugar.

Este es un error crítico para cualquiera que ejecute n8n en producción. ¿Alguien ha encontrado una solución alternativa para omitir esto mientras esperamos una corrección oficial del equipo de n8n?

No veo que los datos fijados se ejecuten en producción. Solo que el panel de ejecución muestra los datos fijados en lugar de los datos reales del disparador. Si tienes prueba de que tus flujos de trabajo en producción se están ejecutando con datos fijados, te animo a que hagas un video de eso y lo adjuntes al problema que planteé y vinculé arriba. O abre un nuevo problema y pon “crítico” o “urgente” o algo así en la línea de asunto para que alguien realmente lo revise. Si eso está sucediendo de verdad, es un problema crítico y lo arreglarán inmediatamente.

Mi problema fue cerrado como duplicado de un problema anterior que dicen fue una regresión (forma elegante de decir «un error involuntario que fue introducido por una nueva funcionalidad y que rompió algo que ya estaba funcionando») y que ahora se corregirá en la versión 2.22.6. Se disculparon por las molestias.

@adriandotgoins @Thiago_Domingues @Evan711 bienvenidos a la comunidad n8n.
nueva release el 01/06 con correcciones.

Release notes | n8n Docs

@adriandotgoins

¡Absolutamente tienes razón! Después de hacer algunas pruebas más profundas basándome en tu respuesta, me di cuenta de que el problema es efectivamente visual, tal como lo describiste.

Los datos entrantes reales se están procesando correctamente internamente. Sin embargo, el factor más agravante aquí es que el panel de ejecución enmascara completamente esto. Muestra el flujo de trabajo procesando los datos fijados, lo que significa que perdemos completamente la capacidad de inspeccionar o acceder a los datos reales de producción en los registros de ejecución.

Así que, aunque técnicamente no está rompiendo el flujo enviando datos simulados a producción, se convierte en una pesadilla para la depuración y el monitoreo, ya que solo tenemos acceso a los resultados visuales de los datos fijados.

Me alegra mucho escuchar que lo han reconocido como una regresión y que una solución ya está en camino para la versión 2.22.6. ¡Gracias por orientarme en la dirección correcta y aclarar el comportamiento!

La etiqueta «Pinned» (Fijado) en el registro de ejecución es un registro histórico; muestra lo que realmente se ejecutó durante esa ejecución específica, no el estado actual de tu flujo de trabajo.

Qualquier ejecución que se activó mientras el nodo estaba fijado mostrará «Pinned» permanentemente, incluso después de que lo desfijes. Esa parte es lo esperado y no cambiará.

La pregunta es si las nuevas ejecuciones después de desfijar + republicar también muestran «Pinned». Si es así, primero intenta una actualización forzada (Ctrl+Shift+R); a veces el navegador sirve una versión almacenada en caché del flujo de trabajo, y el desfijar en realidad no llega al servidor. Luego activa una ejecución nueva y verifica esa específicamente.

Si las nuevas ejecuciones aún muestran «Pinned» después de la actualización forzada, exporta el JSON del flujo de trabajo y busca una clave pinData en ese nodo. Si sigue ahí, el desfijar no se persistió; la guardia falló silenciosamente.

Elímina del JSON, reimporta, republicar, y deberías estar listo.

Gracias por tu minuciosidad. El contenido generado por IA está haciendo esto desagradable

Hice otro post aquí: Pinned Node in execution view is annoying