I’m not sure when this was updated or maybe I’m using it wrong but I’ve noticed that if I have a pinned node in my workflow any executions that run while that pinned node is published will have the pinned data overwriting the actual execution data. I feel like the execution view should prioritize the executed data not pinned data that is being used for testing.
Now I have to make sure everything is unpinned before testing. Small problem but still inconvenient. Please help me understand why this change was made.
Normal workflow will go from node A to node B. If I have “rubbish” data, will it cause workflow to error out and crash? Does this make sense, @Chrevor?
I have to respectfully disagree that this is the expected behavior. Historically, pinned data has always been a feature meant exclusively for manual canvas testing.
If production executions are now using pinned data instead of processing the actual incoming request data (from triggers/webhooks), it completely breaks the development lifecycle. It is very common for us to pin data to test a specific branch of a workflow in the editor, while the published version continues to run in the background.
Because of this change, we are now facing critical errors across our instances. Our production workflows are returning incorrect data because they are ignoring the real live requests and strictly using the pinned mock data instead.
Could the team please re-evaluate this? Production should always prioritize real incoming data, and pinned nodes should not interfere with active executions. This feels like a major regression.
Ah…everything looks different when my brain is lacking sleep. What @Chrevor and @Thiago_Domingues stated is true according to the documentation.
However, from a programmer’s or developer’s point of view, you do not always turn on debugging mode when your program is running live. Hence, I do not have this habit of pinning data with my published workflow. This had likely saved me the pain of what is happening now
